View Full Version : New renderer
July 21st, 2004, 08:56 AM
I think I owe you a new screenshot of the new renderer. That time, you can see the level (in fact, it's playable for the first time because you actually see what you do)
Once again, I hope you like the constrast ;)
July 21st, 2004, 09:07 AM
The contrast is.. very well noticable.
Still a long way to go i bet.
I would say "good job" and all sorts of that thing if i knew what i was talking about, but since i don't know anything about programming, i'll let the wise people give those comments. I'm just glad to see progress.
July 21st, 2004, 09:08 AM
Good to see the progress. The older one was more contrastful though...
July 21st, 2004, 09:39 AM
My eyes! :p
July 21st, 2004, 10:23 AM
I see you are using the LSD Doom pwad. That's, like, cool man.
July 21st, 2004, 10:41 AM
WOAH! Doom3 ain't got nothing on that!!
July 21st, 2004, 10:58 AM
Wow, what a better birthday present than a pic of the new renderer. Thanks Hurdler ;)
July 21st, 2004, 02:07 PM
Neat, you can see the handywork of the nodes builder. Intuitively you'd think it would be a bit more symmetric. Now take that screen a bunch of times after rebuilding the wad with different programs. :p
July 21st, 2004, 02:52 PM
Oh, sorry if there are some holes in the walls, I haven't used Zennode on the map before taking the screenshot. I'll show you one with the result of Zennode in the next few days.
Oh, and even if that looks far from finished, it's not that far (it's just I can't show you the improvement in the current state).
Happy birthday Iori !
Exl, yes sorry, I did some optimisations at the expense of a little bit less contrasted result. Sometime in your live, you have to make choice!
July 21st, 2004, 07:55 PM
Keep up the good work Hurdler. I'd buy you a beer now if I was anywhere near you. :D
July 21st, 2004, 08:02 PM
Oooo.. all the prtty colors...
July 23rd, 2004, 02:34 PM
Ok, here is as promised the one after applying Zennode.
July 23rd, 2004, 02:48 PM
Helloooo nurse! It sure shows how much Id's nodesbuilder actually sucked. Nice to see walls and floors too BTW :)
July 23rd, 2004, 02:49 PM
Oh agreed. This looks awesome. If I had the proper organs I would bear your children.
..Well.. not really. *rofl*
July 23rd, 2004, 02:54 PM
hey, BTW, I don't know if you have already noticed it, but we are no longer limited by the doom palette in those screenshots ;) Those are true 32 bits textures!
July 23rd, 2004, 03:12 PM
Yep that is indeed looking very good Hurdler. Are they colour grouped by subsectors?
All the pinks and purples kinda gave the true colour away... :)
July 23rd, 2004, 03:29 PM
They are grouped by subsectors but floors, ceilings, walls (bottom/mid/top) use different (random) colors.
Ok, next screenshot will be with gr_hirestextures set to on (instead of simply gr_hires on), as I forget to active that cvar before taking it.
July 23rd, 2004, 09:14 PM
Looks great *thumbs*
July 23rd, 2004, 09:49 PM
*drools over all them prtty colors*
...I can just imagen how it much be to play the game like that XD
July 23rd, 2004, 10:21 PM
Go Hurdler! :D
July 24th, 2004, 11:05 AM
Hey Hurdler, you should keep that mode around in the engine for map debugging purposes. :D
July 24th, 2004, 02:36 PM
i must say this is better than the black and white checkerboard :P
kickass , this is gonna be shweeet ! *cool*
July 24th, 2004, 02:45 PM
Aliotroph, in fact, something similar was already there in the old code. You could desactivate texture, but no *nice* colors were used instead.
But yes, that's an idea to change those "compiling" flags to cvar as it might be interresting for map authors as well. One of the flags I wanted to aad is one which show you the unecessary draw overhead, for instance when an object (sprite/wall/floor...) is drawn even if it's then overwritten by an other object). It might help do redesign some map when the author see slowdown.
July 24th, 2004, 02:54 PM
most older authors shouldn't need something like that , but for some things yet it still might come in useful.
I know is a bit early to ask this maybe but will the c++ version have less of a limit on vertex's?
July 24th, 2004, 03:13 PM
That's a cool idea Hurdler.
I must say I'm impressed with how much better that map looks after you used ZenNode on it. I knew it would be a lot better but it looks like art now. :D
EDIT: I see some sparkles in that screen (front left of steps). I see those in new games too, including Half-Life and Heretic II. What causes them?
July 24th, 2004, 04:12 PM
yes, most of the limits (if not all) will be removed. At least, there won't be hardware specific limits (in the current state of the new renderer those limits are already removed).
That's something you can already see in the old renderer, it's called T-Intersection (or T-Join) issue. That happens when two adjacent triangles don't share two identical vertices. Due to mathematical error (because float are 32 bits and not infinite precision), you can have gaps (or overlap, but that's less annoying) between the two triangles.
If you want to know why it's called T-intersection, you can have a look here:
http://www.opengl.org/resources/tutorials/sig99/advanced99/notes/node13.html (look at the picture, you can see a T)
Now, there are algorithm to remove T-Intersection, that's what the gr_solvetjoin do (on by default), but unfortunately, it doesn't remove 100% of the T-intersection, yet (that's something I'll look into when the renderer will be working good enough)
July 24th, 2004, 09:16 PM
Ah, I see how that works now. Yeah, removing 100% of those is probably technically impossible.
It's just interesting to see some games do it more than others. Some Legacy maps do it a lot. Half-Life does it a lot too (especially the beginning train scenes going into the caves). I've never noticed it yet in JDoom or a Quake game though. I've noticed they can be hidden by using a dark colour for the sky in the back (if there's no sky in your map).
Well, it's a minor thing anyway. Like I said, keep up the good work. The new Legacy will be awesome. :D
July 25th, 2004, 01:25 AM
I think there are lots of them with walls. The gr_solvetjoin cvar works only on floors, I think. It simply happens when two adjacent sectors doesn't have the same height. In fact, the walls are currently always drawn with a rectangle (2 rectangle triangles), while they should be drawn with more than 2 triangles when two adjacent subsectors have a different height. That is easier to fix with the new renderer code because now walls are a set of triangles and not necessary a single rectangle.
July 25th, 2004, 10:17 AM
I see how that works. You just made me feel like starting up JDoom in wire-frame mode to see how it draws the walls. This stuff is pretty neat. :D
July 26th, 2004, 09:22 AM
my openGL rendere never has problems with that in half-life, quake2 or quake3. but as soon as I put my legacy doom in GL they were all over the place (I run in software because of this). I think there might be a way to fix it if the triangles are scalable instead of set to a size you might be able to draw them all like this /\\//\\/ so that the flat eddg always hits the corner so t-joints don't get errors or if you make a node builder with over-laping walls and edges it might remove most of the errors. I used a simalar method (overlaping walls) in a half life level because my freinds computer had errors in t-joints
I read the part about the no texture option and it just hit me like a brick. my Dday won't draw textures in GL mode, If I knew the command for the texture draw or surface off-set I might be able to fix it. Is there a command like this in the curent ver? of Dday. when I use GL the color of the textur shows but no texture.
July 26th, 2004, 10:12 AM
For t-join, I know pretty well how to fix them. Overlap is not an option (even if that probably works most of the time without too much side effects). If we can do it properly then we must do it properly.
July 26th, 2004, 03:15 PM
Doesn't SSE2 support 64bit floating point precision? I doubt many Legacy users have a P4 or A64 though.
July 27th, 2004, 01:19 AM
All modern processors have 64-bit floats ("double precision", called "double" in C/C++).
It's just that they require twice as much memory as 32-bit floats...
July 27th, 2004, 03:16 AM
That said, graphics card doesn't support them. All double are converted to float. The precision problem is still there (and I'm sure you could still see the problem even with 64 bits floats).
July 27th, 2004, 11:09 AM
well I think you'l have no problem figuring it out. there is only one thing, If Valve software has problems with t-joints and has to use overlaps (check out the elevator in the training course) It might be prety difaculte to find a solution. as for the 64 bit floats, dosn't the engine have to support some kind of 64 bit interface for that to make much of a diference?
July 27th, 2004, 12:04 PM
JNOD: If you are talking about overlaps as in level geometry, the half life compilation utilities remove them when you compile the map anyway, to reduce the complexity of the .bsp.
July 27th, 2004, 12:19 PM
JNOD, that's not because a game company couldn't solve a problem we couldn't. We are not newbie in the domain. Just for your information, I also worked for a company who do business with 3D games. If Legacy has the bug, that's simply because we didn't take the time to investigate the problem in the past, that's all (and it's more a matter of time than a matter of competence). Note also the 2D bsp in Doom is probably much easier to handle than a 3D bsp for that kind of stuff.
About the HL issues, I don't know them since I've never played the game, but if you talk about an elevator, I suppose you are talking about dynamic geometry, that's something different.
vBulletin® v3.8.5, Copyright ©2000-2013, Jelsoft Enterprises Ltd.