HL2 Expectations
Post Reply
Quote
Re: HL2 Expectations
Posted by ReNo on Sat Dec 11th at 8:05pm 2004


I'm not entirely sure on the tech of these things, but I'll try and explain why models and BSP geometry are different in rendering costs...

BSP geometry (as in brushes built in hammer) are quite a bit more taxing for the game than a model, because all of it needs to be in memory. Models are loaded into memory once each and any instances of them in your map are just references to the same model. So if you have 20 pillars in a room, if you make them in hammer then the same data will be put into memory 20 times, while if you make them in a modelling program and put them in as props, the geometry data is loaded in once and referenced for each location. Obviously details are then changed for each reference, such as bullet holes and any sort of deformation that the instances can have, but the memory difference will be signficantly less regardless.

As for rendering performance, it probably has a fair amount to do with simpler lighting routines. In source, BSP geometry is lit with pretty high resolution light maps, while props are lit with much simpler vertex lighting. Also, somewhat complex objects built in a modelling package can normally be made using far less polygons than hammer. They will also not suffer from face splitting due to overlapping or BSP segmentation.

Again, I'm not overly confident I'm correct on all of this, somebody like Andrew would be better able to answer I'm sure.
[addsig]




Quote
Re: HL2 Expectations
Posted by scary_jeff on Sat Dec 11th at 9:29pm 2004


Hardly any of the lighting on world stuff is done in real time though, is it? All it has to do is display what the compile tools worked out before hand (and at great length)



Quote
Re: HL2 Expectations
Posted by Crono on Sat Dec 11th at 9:31pm 2004


? quote:
Hardly any of the lighting on world stuff is done in real time though, is it? All it has to do is display what the compile tools worked out before hand (and at great length)


Right. If all lighting was calculated in real time it wouldn't run. Dammit, light is so complex. (Thus RAD calculates highlights and shadows and everything else has a base light amount) However, I'm not sure about dynamic lighting. That has to be somewhat calculated real time. I bet dynamic lights have severly less quality then normal lights. And a cleaner algorithm.

I know I s**ttly explained it because I'm not entirely sure on how it is more effecient. Sorry
[addsig]




Quote
Re: HL2 Expectations
Posted by Nickelplate on Sat Dec 11th at 9:31pm 2004


difference between 3d rendering and real-time is like the difference between a sprite and a model. sprites are rendered 3d images, whereas models are compiled 3-dimensional wireframes with a 3d rendering wrapped about them. a sprite is just the skin that changes position based upon what direction it is being viewed, and it is user specific. [addsig]



Quote
Re: HL2 Expectations
Posted by Jezpuh on Sun Dec 12th at 3:04am 2004


I was dissapointed because of the fact that there weren't any real alien weapons except for that stress ball.. thing.
[addsig]




Quote
Re: HL2 Expectations
Posted by ReNo on Sun Dec 12th at 3:27am 2004


Once again, I have to point out my knowledge on this isn't perfect, but I'll try to clarify the lighting differences a little.

Lightmaps are calculated during the compile process. These are then overlaid onto faces and the colour of the screen pixel is calculated by the chosen texel (the name of a single texture unit) and the respective luxel (I think thats its name - the lightmap equivelant of a texel). I'm not sure if the lightmap and texture are combined during the compile or at run time, but for switching lights or lights with any effects (note: NOT dynamic lighting, but light entities with any "appearance" setting) it would need to be real time I guess.

Obviously that isn't true of dynamic lighting, such as explosions, muzzle flashes, the flashlight, and any light_dynamic entities you make. I can only speculate on how this is done, possibly using lower resolution lightmaps or something made in real time?

Vertex lighting is pretty simple. The light value at the given vertex is calculated, and the face is rendered by interpolating the light values at each vertex and adding that value to the texel colour. Figuring out the lighting value based on the world around it need only be done once per vertex, rather than once per texel like with the lightmaps. Obviously this means no small shadows will effect props, unless the shadow happens to fall over one of the vertices of the model.

Please note that some of this may be incorrect, but its my understanding of the various lighting types.
[addsig]




Quote
Re: HL2 Expectations
Posted by wil5on on Sun Dec 12th at 9:07am 2004


I imagine for dynamic lights, it just temorarily changes the value of the luxel at a given point. Of course, I imagine you are a bit more... enlightened than I am on the topic than myself, but this is what I'm assuming. Makes sense to me, anyway.

[addsig]





Post Reply