3D Models?

[Graf Zahl]

The problem with this is that many of the old rendering tricks won't work anymore.

Speaking of rendering tricks and OpenGL, I wonder why every OpenGL port of Doom has adopted the Quake way of doing things. IMO, Ken Silverman is the only one who got it right when he wrote Polymost. The primary difference between that and his original engine is that Polymost clips edges and software Build clips pixels. Floors and ceilings are still drawn as extensions of the walls, just like the software engine did it; there is no fundamental change to the way the scene is rendered.

If somebody were to adopt that for Doom (which basically means ZDoom, since Polymost is not GPL, so it can't be used with GPL ports), you wouldn't need to rebuild nodes, and every software trick would automatically work without any extra effort.

It may help rendering some tricks but I honestly think that it is not worth the trouble. Having true polygons definitely has its advantages. Yes, it means that it can't handle some of the more elaborate tricks but Risen3D has proven that it is not impossible and with very little additional work the most common rendering tricks (holes with non-textured lower/upper linedef parts), self-referencing sectors) can be easily handled. And there aren't that many maps with those truly hideous tricks.
Anyway, most GL ports have problems not because they use polygons but because there are no means to analyze and handle the rendering tricks:

-Vavoom and ZDoomGL completely lack any code whatsoever to do it and screw up abysmally when they encounter such a map
-Doomsday can handle some basic self-referencing sector stuff but it is really limited
-PrBoom uses the GLU tesselator (which was unfortunately removed in 2.3.x thus making those GL versions utterly useless...) which means that it automatically handles all self referencing sector stuff and it has some primitive handling of non-textured holes
-Risen3D has the most complex analyzer so far and aside from some maps which have node-sensitive tricks it was able to handle everything I saw so far in a decent manner.

As for GL nodes, they aren't really necessary. PrBoom for example has used the GLU tesselator to create its flat polygons. GL nodes are certainly cleaner but IMO they create far too much overhead and quite frequently slow the renderer down.

The most annoying problem of software renderers are their clipping problems. From a quick look at this polymost stuff I can't tell how this would be handled (or how depth buffering is handled at all in it.)

[Chilvence]

*bump*

IMO, Ken Silverman is the only one who got it right when he wrote Polymost. The primary difference between that and his original engine is that Polymost clips edges and software Build clips pixels. Floors and ceilings are still drawn as extensions of the walls, just like the software engine did it; there is no fundamental change to the way the scene is rendered..

This is quite actually fascinating, only nobody explained it in laymans terms . Does this mean that in polymost the floors are just stretched from the walls to the bottom of the screen?

[Graf Zahl]

Basically yes. I can't say precisely what it does but from the basic outline it looks like it does not produce proper depth values. If that is true it is actually pointless to think about it. The main attraction of OpenGL are the enhanced effects - and for those proper depth information is essential. And that's probably the reason why everybody is using real polygons.

[Chilvence]

So, for example if a model were to go below the floor height for some reason, it would be pasted over the floor instead of being cut in half where it intersects with it?

[Mantis]

Of the three source ports that were listed on the first page i find
Risen3D to be teh best one, the 3D characters happen to be pretty damn
close to the sprites.... Except the demon model which is really cheesy,
too cartoonish

[randi]

Basically yes. I can't say precisely what it does but from the basic outline it looks like it does not produce proper depth values.

Oh, but you are wrong. If that were the case, then it wouldn't texture map floors and ceilings properly. (The texture coordinates drawpoly gives OpenGL are only specified in 2D, so the depth information must come from the accompanying 3D vertex.) This method of doing floors and ceilings is even alluded to in one of the readmes that came with the 1.10 Doom source, so I'm surprised nobody ever did it for Doom.

What I think makes Ken's approach really clever though is not the way the ceilings and floors are drawn but the way he made the clipper work. He was able to adapt the existing rendering code for use with Polymost with little effort. If you want to understand how it works, here are some hints: Hint 1: Play with the prototype BASIC code Ken put on his website. Hint 2: As far as the clipper is concerned, there is only one rotational axis (just as was the case with the software rasterizer). Pitch and roll are calculated at the start of drawpoly, after clipping has already been performed. Hint 3: The points passed to drawpoly only describe the polygon's area on the screen. You need to do some more calculations to obtain the texture coordinates and the 3D vertex that belong with each 2D screen point.

There is the slight problem of HOM behind the zenith when you look too far up or down, but that should be fixable by doing a second rendering pass for the areas behind the player. Just clip the viewport trapezoid to the back of the SCISDIST plane instead of the front, and maybe do some flipping.

[Graf Zahl]

Basically yes. I can't say precisely what it does but from the basic outline it looks like it does not produce proper depth values.

Oh, but you are wrong. If that were the case, then it wouldn't texture map floors and ceilings properly. (The texture coordinates drawpoly gives OpenGL are only specified in 2D, so the depth information must come from the accompanying 3D vertex.) This method of doing floors and ceilings is even alluded to in one of the readmes that came with the 1.10 Doom source, so I'm surprised nobody ever did it for Doom.

Ok, I only took a quick look at the basics and it looks a little complicated so I apparently missed the texture stuff. So why didn't anybody use it for Doom? I have no idea whether there are other problems of any kind but it was probably easier to do the GL nodes thing (or something similar to polygonize the sectors.)

What I think makes Ken's approach really clever though is not the way the ceilings and floors are drawn but the way he made the clipper work. He was able to adapt the existing rendering code for use with Polymost with little effort. If you want to understand how it works, here are some hints: Hint 1: Play with the prototype BASIC code Ken put on his website. Hint 2: As far as the clipper is concerned, there is only one rotational axis (just as was the case with the software rasterizer). Pitch and roll are calculated at the start of drawpoly, after clipping has already been performed. Hint 3: The points passed to drawpoly only describe the polygon's area on the screen. You need to do some more calculations to obtain the texture coordinates and the 3D vertex that belong with each 2D screen point.

Since I have no time to mess around with this code myself I have one question: Since this stuff completely works in screen coordinates, how does it handle viewing up and down: Does it just shift the view up and down like Doom or does it do a genuine rotation?

There is the slight problem of HOM behind the zenith when you look too far up or down, but that should be fixable by doing a second rendering pass for the areas behind the player. Just clip the viewport trapezoid to the back of the SCISDIST plane instead of the front, and maybe do some flipping.

So there is a problem...

[randi]

Since I have no time to mess around with this code myself I have one question: Since this stuff completely works in screen coordinates, how does it handle viewing up and down: Does it just shift the view up and down like Doom or does it do a genuine rotation?

No, it has a full 6 DOF. The other rotational axes are handled near the top of drawpoly under the "Up/down rotation" and "Tilt rotation" comments.

So there is a problem...

Yes, but it seems pretty minor. It's only capable of drawing a 180 degree arc of the map, so if you look up or down too far, it needs to scan behind the player as well as in front. So just do another pass that scans behind the player instead of in front, if it's needed.

I've spent enough time studying the code that I have a pretty good idea of how it works, but not enough time to validate all the math.

[Chilvence]

Hmm. Timmie has mentioned a few times that he intends to re-write the ZDoomGL renderer at some point again. If you want to make your case, now's probably a good time

I am going to direct him to this thread anyway, I'd be intrested to know everyones opinion on this.

[Cutmanmike]

.... This thread hurts my brian

[Enjay]

.... This thread hurts my brian

Pilate Alwight, I'll give you one more chance! This time I want to hear no Weubens, no Weginalds, no Wudolph the Wednosed Weindeers...
Biggus Dickus No Thpenther Trathieth!
Pilate Or we shall welease no one!
Judith Release Brian!
Man Oh yeah, that's a good one!
Crowd Welease Bwian! Welease Bwian! Hahahahaha!
Pilate Vewy well, that's it!
Centurion Sir, we have got a Brian, sir.
Pilate We do?
Centurion You just sent him for crucifixion, sir.
Pilate Wait! We do have a Bwian! Well, go on, wepwieve him, stwaight away!
Centurion Yes sir!
Pilate Vewy well! I shall welease Bwian!



Sorry for the distraction.

So, it sounds like what is being said is that there could be an alternative way to render stuff in Zdoom (or any other doom engine), taking advantage of some clever programming by Ken Silverman, that would allow OpenGL goodness, but also leave most (all?) Doom rendering tricks intact and also remove the need to do things like run a BSP style program on the levels. Is that right?

If so, it sounds very interesting indeed.

[Woolie Wool]

That's reserved to OpenGL ports. With a Doom-style software renderer it can't be done.

It can be done without GL, but it will look like crap (see Quake 1).

[Graf Zahl]

That's reserved to OpenGL ports. With a Doom-style software renderer it can't be done.

It can be done without GL, but it will look like crap (see Quake 1).

You didn't understand what I was saying.

I never said it can't be done with a software renderer - it can't be done with a Doom style software renderer. Of course you can do a polygon-based z-buffered software renderer but what's the point? You don't gain anything, your levels still don't look better and worst of all - rendering tricks stop working. Just check out Vavoom if you want to see such a thing.

[Lexus Alyus]

This is quite intresting. It makes me think that randy is indeed planning something big... or am I just too optimistic .

Anyway, I'd like to argue with grafs point that a lot of Open GL ports can't render some illigal sector tricks that software ports can. My point is that these open GL ports can do these ytricks without the need to use these illigal tricks, so, why woudd these ports need to render these tricks? If you are using the port to play a spacific map made for that port then trhere is no problem here, if you are using the port to play old levels then use another port. I think these GL ports are great but only for creating a new type of expreiance.

I personally wouldn' want model support because I'd want to use the current models (thy suck). I'd want to use it to create psuado 3D floors (like rott I suppose) or decorations like cars... ta know, static stuff (look at the ships in Dark Forces... they are badly textured but threy look pritty cool in ame because they are not sprites ... can you imagine how crap that ship woulf look if it was a sprite? ). I'd also use models to create new monsters in an attempt to create a new game. I'm speaking from thew editors point of view, but to be honest, the general rule IMO is to use GL ports for creating a new experiance, not to play an old ewxperiance because it's not compatible.

Backwards compatibilty is great, but it's not gonna happen with gL ports... although Idon't want to discourage graf from what he's doing... he could potentially push the doom comunity forwards, keep up the good work man .

[Graf Zahl]

This is quite intresting. It makes me think that randy is indeed planning something big... or am I just too optimistic .

Anyway, I'd like to argue with grafs point that a lot of Open GL ports can't render some illigal sector tricks that software ports can. My point is that these open GL ports can do these ytricks without the need to use these illigal tricks, so, why woudd these ports need to render these tricks? If you are using the port to play a spacific map made for that port then trhere is no problem here, if you are using the port to play old levels then use another port. I think these GL ports are great but only for creating a new type of expreiance.

What are you blabbering? A Doom port that has problems with many vanilla maps is no Doom port at all! Of course they should be able to handle at least the basic tricks. Self referencing sectors and untectured holes are easy to detect and thus should be handled. Unfortunately most GL ports don't - most likely because the programmers are too stuck in their traditional way of thinking about hardware renderers. Risen3D proves that it can be done. It's a shame that ZDoomGL can't handle many great WADs properly - among them P:AR, Daedalus (a few maps only), Eternal (probably the biggest stumbling block of all...) and many, many others. And yet 90% of these maps could be handled with minimal effort in the rendering code.

I personally wouldn' want model support because I'd want to use the current models (thy suck).

So you don't want models because the ones currently available suck? Some argument...

I'd want to use it to create psuado 3D floors (like rott I suppose) or decorations like cars... ta know, static stuff (look at the ships in Dark Forces... they are badly textured but threy look pritty cool in ame because they are not sprites ... can you imagine how crap that ship woulf look if it was a sprite? ). I'd also use models to create new monsters in an attempt to create a new game. I'm speaking from thew editors point of view, but to be honest, the general rule IMO is to use GL ports for creating a new experiance, not to play an old ewxperiance because it's not compatible.

So you prefer to hack around instead of preferring a clean implementation...

Backwards compatibilty is great, but it's not gonna happen with gL ports...

That's nonsense. Risen3D proves otherwise. It's just that some programmers don't bother to invest the time to find and code a solution. Just take a look at ZDoomGL for example. It's as straight a GL port as they come. It blindly assumes that all sectors are closed, all walls are properly textured and the map doesn't do anything out of the ordinary. With such an approach you have already lost.