[Not ZDoom] Rendering Issues

[Blaxen]

Hi all,

I created a map using DeePsea under the ZdoonHexen project and ran it under ZdoomGL. When I load my wad and start going through the level I notice the engine refuses to render properley in place of some nodes.

An exmaple below:



What could be causing this?
I already ran zdbsp and had it fix the nodes for GL, but that made no difference.
I'm using an NVIDIA RIVA TNT2 Model 64 Grpahics card at 4X AGP with an AMD Athlon XP 1.6Ghz Processor.

[Cyb]

this is a zdoomgl error, not a zdoom problem, make a bug report at the zdoomgl forum: http://www.doomworld.com/vb/forumdispla ... forumid=21

[SirTimberWolf]

FireBastard
Green Marine

Posts: 40
Registered: 06-03



--------------------------------------------------------------------------------
Cyb said:
zdbsp's primary draw is that it's aware of polyobjects and can stop bleeding where other builders, including zennode, can't. it can also build gl nodes (I can't think of any builder that can build both gl and std nodes) and in the future it will be able to build a new format of compressed nodes that will be useable by ogl and std rendering engines (zdoom only of course). but essentially if you're making a zdoom (or hexen) map, zdbsp is your best choice by far
--------------------------------------------------------------------------------


GLBSP builds both regular and GL nodes - explained in the docs - should be a default. Guess I can see his reason for not defaulting the way he did.

Biggest thing that pisses me off about ZDBSP is that it really screws up 3D bridges. Also does not work well with GL ports if you use GLBSP to derive the GL nodes from (again read the docs).

Seems to be concocted in combination with ZDOOM code to work well with its renderer only.

I use zennode, deepbsp and glbsp depending on the level or port. Sometimes zdbsp for for ZDOOM only. Too many issues with it.



THis is from the doomworld forums I hope this helps out somewhat

[HotWax]

ZDBSP only exists because people wanted some way to save the nodes ZDoom generates automatically when you have gennodes set to 1. As such, the code came 100% out of ZDoom itself -- there was no reason to have ZDoomGL (or anything else) in mind when Randy wrote it. At the request of forum-goers, he stuck it in its own executable and released it. So don't complain, the alternative is no ZDBSP at all.

[Kappes Buur]

.
If it is the see through walls "bug", then go

there -->> http://www.doomworld.com/vb/showthread. ... adid=15364
.

[Cyb]

considering 3d bridges (the doom2.exe way) are really rendering errors due to inaccurate nodes, it's actually zdbsp's fault for being too accurate ; )

besides, if you're making a zdoom map (which is what I recommend zdbsp for) you don't need to make the old style 3d bridges

[Curunir]

Wait, what "old style" bridges?
I can't think of another way of making a 3d bridge apart from Zdoom's Bridge thing. But now that I think of it, I've seen vanilla Doom maps that had these.
What would be the "old style" and the new one?

[Chris]

Raising/lowering invisible sectors, I believe is how they'd do it the old way. The new way is of course to use invisiable bridge objects.

[HotWax]

Wait, what "old style" bridges?
I can't think of another way of making a 3d bridge apart from Zdoom's Bridge thing. But now that I think of it, I've seen vanilla Doom maps that had these.
What would be the "old style" and the new one?

To put it in simple terms, the Doom renderer is.. uhhh... easily fooled. The basic setup is thus:

Create the sector you want to be invisible.
Create a sector contained entirely within it. This will actually be the part you stand on, so make it as close to the lines as you think you'll need.
On all the lines that make up the inner sector, change the sidedef sector references so that they ALL reference the inner sector. When this is done, you'll be able to tell because the editor will highlight the inner sector correctly while the mouse is in it, but when you move the mouse between the inner and outer sectors, the inner sector will NOT be hilighted as part of the outer. (Yeah, that sounded coherent alright) Just try it, you'll see what I mean.

That should be it. Oh, and I honestly don't recall where you need to set the floor heights. I'm 90% the inner sector needs to be set to the height you want the player to "float" on. The outer sector either needs to be set to the same height, or else the height of the surrounding (lower) areas. You'll have to experiment.

You can also create invisibile pits this way, just make the inner sector lower than the surrounding floor. If the player falls in these, he'll see nasty hom, so it's best used to hide enemies in the floor and then raise them instantly to make them "appear" out of thin air.

Of course all these effects can now be handled (and better) by ZDoom, but it's always nice to know the tricks of the trade.

[Curunir]

Pure evil, HotWax!
Yes, I remember seeing these insta-raise monster pits. And thanks for the explanation of the old bridges.

[Graf Zahl]

And don't even think about using them in modern WADs for a source port.
This kind of stuff is problematic when it comes to OpenGL and there are better methods available now. The bridge things already mentioned are one option but if you really nead an invisible block in a level better use the Transfer_Heights special. It produces the same result but without the ugly side effects.

[randomlag]

RISEN3D (OGL) handles "old" style bridges no problem. Actually ZDOOM does too, so long as you don't use ZDBSP (that tells you something)

The implicit goal of any port is backward compatibility with existing levels (including abuse of the engine) - witness the bitching about minor changes (some actually make for a better game) just because it isn't like DOOM This isn't always easy, but it is possible.

[Graf Zahl]

I was mostly talking about the BSP problems. Detecting the most common cases of open-sector-hacks for rendering is rather easy but if the player cannot stand on the bridge it's bad.

For example, I once fixed a bug in E1M3 of Phobos: Anomaly Reborn but I was totally unable to rebuild the nodes so that the crane worked. Not a single node builder I tried did it right.

The implicit goal of any port is backward compatibility

Well, ZDoom is doing rather well in that regard. The most significant changes are either compatibility optioned or a real improvement so that almost nobody complains.

There are source ports which are doing much worse (did I mention Legacy? )

[randomlag]

Those Legacy guys try very hard to accommodate their users' wishes. Just because different ports have different goals is no reason to keep putting them down.

VAVOOM technically (renderwise) is probably one of the most advanced of any "DOOM" port - just with very different goals/coding. Really has some amazing 3D construction, lighting, models, etc. http://forums.vavoom-engine.com/

Btw, all I mentioned was the old way of doing bridges is fine (and implicitly required for backward compatibility) since you said:

And don't even think about using them in modern WADs for a source port.

PAR is constructed with an unusually high number of "sector not closed" areas. What exactly is the mistake since there technically are many?

FYI : The PAR levels are what RISEN3D used to perfect the GL renderer - that's his primary goal: to display any and all DOOM levels (that display ok in the stock engine or BOOM/MBF) with no anomalies.

There are many many variations in most node builders just by tweaking the settings. One common one they share is the "split factor", that alone will give you about 16 reasonable variations. Most users are not aware of the big differences that can result. DeepBSP can only be tweaked from within DeePsea - the defaults are ok for most, but not all levels or ports. For starters, I'd probably use the auto split option on E1M3.

[Graf Zahl]

FYI : The PAR levels are what RISEN3D used to perfect the GL renderer - that's his primary goal: to display any and all DOOM levels (that display ok in the stock engine or BOOM/MBF) with no anomalies.

This port sounds really interesting and I'd really like to check it out more in detail. Unfortunately there is no source code available (which for someone like me who loves to hack around with stuff like this makes it rather useless... )