SiO2 on 3/1/2009 at 10:17
Quote Posted by Volca
Hmm. Object lights indeed need a few fixes - radius is often too small or too large (those damned infinite radius lights :) )
Directional lights in GL/D3D have a direction but no radius (and no attenuation). Would these do the job?
Quote Posted by bob_doe_nz
Is there a light_bright function in OPDE?
Perhaps implementing gamma functions would be the quickest route. Being able to press + or - to adjust gamma in-game is really useful in my opinion. I assume Ogre has some form of Gamma interface that would allow this to be easily implemented.
Volca on 3/1/2009 at 11:59
Quote Posted by SiO2
Directional lights in GL/D3D have a direction but no radius (and no attenuation). Would these do the job?
Nope - Dark uses infinite and finite radius point lights - the first have linear attenuation (or so it seems), the latter have no attenuation and limiting radius. The current differences to original dark are the ordering of lights (list of lights per object has to be determined somehow) - infinite lights could be ordered differently in original impl, and the radius handling for finite lights is slightly different. Nothing hard to fix, just requires preparing a well designed testing mis file in dromed and comparing the output for a few edge cases.
Quote Posted by SiO2
Perhaps implementing gamma functions would be the quickest route. Being able to press + or - to adjust gamma in-game is really useful in my opinion. I assume Ogre has some form of Gamma interface that would allow this to be easily implemented.
There was no gamma setting in ogre last time I checked... I plan to implement this ourselves (some platform utilities should be coded anyway for savegame paths etc.). LightBright is probably just a question of setting the ambient lighting to maximum, switching off all lights and switching off the lightmapping completely (should be doable).
SiO2 on 3/1/2009 at 13:45
Quote Posted by Volca
Nope - Dark uses infinite and finite radius point lights - the first have linear attenuation (or so it seems), the latter have no attenuation and limiting radius.
Hmmm. A light has an infinite radius yet still attenuates? Doesn't the point at which the light attenuates to zero give a finite radius?
I haven't dug into the Dark internals yet, so you obviously know a heck of a lot more about them than me...
Volca on 3/1/2009 at 13:48
Quote Posted by SiO2
Hmmm. A light has an infinite radius yet still attenuates? Doesn't the point at which the light attenuates to zero give a finite radius?
I haven't dug into the Dark internals yet, so you obviously know a heck of a lot more about them than me...
Well, I'm not sure whether it has linear attenuation. If not, it would in theory have some effect at any range. For now, I decided to scale the radius of these lights with their brightness and make them lineary attenuate. Makes sense to me, although may be not 100% same as original then.
2Dark on 3/1/2009 at 20:07
About object lights - at least on my rig, certain, possibly so called "jointed" objects have illumination issues. Thief2 watchers look as if the other part is correctly lit or at least somewhat correct and the other part is as if it was "unlit" or "fullbright". AI's illumination is ugly and completely off. Framerate is pretty dependant on cpu power at least on my comp. as far as i could see. It doesn't change all that much regardless of resolution or quality settings - tried 640x480 all the way to 1600x1200 with AA and AF at varied settings = very similar to Dark Engine behaviour.
Tested medsci1 level and there was no framerate drop near -that- door of anywhere else on that level for that matter. In fact framerate was quite spectacular, over 130fps at places and around 50-60fps on average.
Corpseholic decorations were standing upright and buried halfway to the ground - unintentionally funny side-effect, half of them looked as if they had been buried and were screaming in terror ;)
Tested some other ss2 large/complex missions, such as rec1 "lobby" and there was no large "long sightlines/large empty spaces" fps drop as in original ss2/thief1 engine as far as I could see. Tested Return to UNN-fm and there were few slow spots, such as the long street with many objects at the beginning and garden.mis garden with its many objects and also passegeway to second level with multiple railings and in all cases framerate dropped to around 20fps. I guess the observation from all this is that this renderer is bit more graceful with many objects at screen than original dark but not that great.
On the other hand Christines Ponterbee station-fm and its notorious hole in the walkway at the rec-deck was smooth and fast > ?no geometry/portal complexity slowdown?. Overall pretty nice - no stability problems whatsoever.
Tested MaxAtlasSize 4096 but since my computer is really a P.O.S it didn't help any.
Specs/OS:
Debian linux/kernel 2.6.28.zen/gcc 4.3.2
Sempron 2200
1.5 GB Ram
GeForce 5500FX 256MB
Nvidia 173.14.15 beta driver
So basically low end of the spectrum :(
I'll just have to test some of those 1000+ polys at view missions next!
Haplo on 3/1/2009 at 22:31
The FPS does indeed depend a lot on the CPU/GPU power. On my (fairly powerful) rig, I cruised through the whole medsci1 level. I got an average FPS of 800 and the worst FPS of 290, best 1180.
The worst FPS while going through the streets of Ponterbee was 331.
Here's my spec:
Intel E8500@3.16GHz
4GB RAM (DDR2 1066)
GeForce 9800GTX+ 512MB
WinXP SP3
Also I don't know about Linux OpenGL, but on every Windows machine that I have tried openDarkEngine, DirectX gave me about 20-30% higher FPS that OpenGL.
Volca on 4/1/2009 at 07:41
Thanks for the tests 2Dark
Quote Posted by 2Dark
About object lights - at least on my rig, certain, possibly so called "jointed" objects have illumination issues. Thief2 watchers look as if the other part is correctly lit or at least somewhat correct and the other part is as if it was "unlit" or "fullbright". AI's illumination is ugly and completely off. Framerate is pretty dependant on cpu power at least on my comp. as far as i could see. It doesn't change all that much regardless of resolution or quality settings - tried 640x480 all the way to 1600x1200 with AA and AF at varied settings = very similar to Dark Engine behaviour.
AI have broken normals - this is the reason for them to look the way they do. I didn't look at the cause yet. The reason why the rendering is so CPU dependant is the way we currently render things - in step one visibility determination is done - completely on CPU. Then, after the list of visible cells is determined, the light lists are populated, etc. The last step is to populate index buffers of the static geometry meshes to contain indices of visible triangles (also CPU bound). At least here we use 16 bit IBOs when possible to save bandwith. Overall much more than half of the frame can be CPU bound (depends on PC configuration).
Quote Posted by 2Dark
Tested medsci1 level and there was no framerate drop near -that- door of anywhere else on that level for that matter. In fact framerate was quite spectacular, over 130fps at places and around 50-60fps on average.
Corpseholic decorations were standing upright and buried halfway to the ground - unintentionally funny side-effect, half of them looked as if they had been buried and were screaming in terror ;)
Yeah, they are all in binding pose now - we need to come up with skeletal animation code first in order to let them rest in peace :)
Interesting - so my PC is probably the only one that suffers the sudden framerate drop issue (I get around 2 FPS :eek: at certain parts of that mission, and it seems all the time is spent in the driver).
Quote Posted by 2Dark
Tested some other ss2 large/complex missions, such as rec1 "lobby" and there was no large "long sightlines/large empty spaces" fps drop as in original ss2/thief1 engine as far as I could see. Tested Return to UNN-fm and there were few slow spots, such as the long street with many objects at the beginning and garden.mis garden with its many objects and also passegeway to second level with multiple railings and in all cases framerate dropped to around 20fps. I guess the observation from all this is that this renderer is bit more graceful with many objects at screen than original dark but not that great.
On the other hand Christines Ponterbee station-fm and its notorious hole in the walkway at the rec-deck was smooth and fast > ?no geometry/portal complexity slowdown?. Overall pretty nice - no stability problems whatsoever.
Thanks for this. I think original dark introduces some per frame cost we don't - the rendering is still done polygon by polygon. I'd still love to try rendering the levels dynamically lit - it could in fact mean better performance (less batching issues).
Quote Posted by 2Dark
Tested MaxAtlasSize 4096 but since my computer is really a P.O.S it didn't help any.
Specs/OS:
Debian linux/kernel 2.6.28.zen/gcc 4.3.2
Sempron 2200
1.5 GB Ram
GeForce 5500FX 256MB
Nvidia 173.14.15 beta driver
So basically low end of the spectrum :(
I'll just have to test some of those 1000+ polys at view missions next!
What the MaxAtlasSize does is it affects the number of batches the static geometry is split into. If the graphic card can render big size images without performance problems, this lowers the batch counts noticeably (typically the level lightmaps are then stored in 1-4 large atlases, instead of 4-8 of smaller ones - and multiply this with texture counts to get batch count). I think this has some noticeable, positive effects only on 8800 cards and up.
nicked on 4/1/2009 at 13:51
Well I don't understand 95% of the technical talk, but I've just tried this out and... Damn that's cool! All the possibilities...
Hiatus on 4/1/2009 at 21:19
Quote Posted by Volca
The reason why the rendering is so CPU dependant is the way we currently render things - in step one visibility determination is done - completely on CPU.
are you guys planning to make future OPDE version (much) less CPU dependent/bound and more GPU dependent, so its fps scales much better with res/AA/AF levels applied? This CPU dependance and lack of performance scaling is an aspect of original DE I really dislike (game needs a powerful CPU still (esp. in more complex/modern FMs but at some places in OMs, too), while - usually available - much more powerful GPU sits idle practically unused - or so it seems). I'd like to see much more modern GPU features/raw power/speed utilitilization in future OPDE versions. Hope it will be possible.
btw which graphics APIs your renderer (based on Ogre engine?) expose: OGL and D3D? And which level/version of each is required at minimum/recommended? (ie. OGL 1.5, D3D 8.0 etc). Which one is faster/more mature/stable, and recommended (you mention that D3D is faster on Windows)?
Volca on 5/1/2009 at 08:22
It is somewhat difficult - it is probably possible to rework the way visibility determination and scene display is done, but it would eat one capable project member for many months, I'd say. I was thinking of doing this myself, but in my opinion it is better to come up with a more complete engine first, this kind of thing can get reworked later on. I tried some other rendering strategies - like splitting the static geometry to big box-like pieces (this eliminates the need to rebuild IBOs every frame), but the batch counts were worse, and visibility determination was still done on cell-portal level (overall worse performance).
One thing that I tend to think could be done is visibility determination and geometry grouping using the room database instead of the cell-portal-bsp structures, but this could have issues if the room db was incomplete for example.
Another thing is the fact BSP tree is used extensively in original engine, and we're not yet in the state we could say it can be dropped without problems.
Ogre3D, which we use for rendering, allows both OpenGL(2.0) and DirectX(9.0, 10.0 is in the works) rendering, and the performance (from my experience) of those highly depends on the hw/driver, not as much on the API itself :)
