New demo!
- Thread starter Humus
- Start date
Some antivirus/firewall programs prevent programs from starting other programs. Depending on the settings of your firewall/antivirus software you will be prompted if you want to allow a program to start another program or the antivirus/firewall will just silently deny it. Many installation programs need to launch other programs during the install process. So if you antivirus/firewall prevents this, your install will fail.Guden Oden said:
Nice demo Humus: your visibility preprocessing work it's someway similar to this:
Directional Discretized Occluders for Accelerated Occlusion Culling
Dunno if you know this work but it's worth reading.
btw, are you using conservative rasterization to make sure the visibility preprocess is not erroneously culling away visibile meshes?
Directional Discretized Occluders for Accelerated Occlusion Culling
Dunno if you know this work but it's worth reading.
btw, are you using conservative rasterization to make sure the visibility preprocess is not erroneously culling away visibile meshes?
Humus said:
GameEngine2.rpt (report?)
this is what is inside:
********************************
Exception code: C0000005 ACCESS_VIOLATION
Fault address: 00CEBC4D 01:0000AC4D C:\WINDOWS\system32\ct_oal.dll
Registers:
EAX:00000000
EBX:00000000
ECX:00000533
EDX:00EC0000
ESI:00DC0048
EDI:00ED2000
CS:EIP:001B:00CEBC4D
SS:ESP:0023:0012EF68 EBP:00000000
DS:0023 ES:0023 FS:003B GS:0000
Flags:00010246
nAo said:
I think I've skimmed through that paper earlier. I seem to recognice it. Not sure if it's that similar to what I'm doing though.
Yeah, the culling is conservative and 100% safe so there will never be any visible objects culled. Some invisible objects may still be drawn though, but that's the case with most algorithms anyway. I think it's fairly efficient in comparison to other techniques (I haven't really done any comparison though). The only really inefficient thing about it is the quite long preprocessing time. But it only needs to be done once and the stored data is minimal and very compressible.
Deathlike2
Regular
Alstrong said:
A good time to update the sound card drivers, yes?
Good thinkingHumus said:
BTW
I love your new demo, and I’m curious is there some trivial explanation why are the PDM (Parallax Displacement Maps) are noticeable becoming flat on corners? Besides that little “dispelling†your PDM is great! Could be possible to sustain acceptable frame rate with little more complex levels, and that PDM of yours?
I’m asking this, ‘cos I think that PDM is equally important as say HDR, maybe even more IMHO! And I totally disagree with FutureMark guy in that interview where he’s trying to explain why they are excluded PDR from 3DM 06!
aye parrallax >= HDR i dont think so! parrallax is a hack IMO often ugly
good stuff humus, youre demos are about the only ones i bother downloading
one change u could make which will double the framerate at least i guess (it is a bit of extra work though)
after youve checked what cells are visable from your visability list
each frame use occlusion test (when u lay down depth pass) check if a light areas receiver/casters meshs are visable, itll save time by not creating unecessary SMs if they dont influence the scene
*another speedup is to use different size SMs based on a light areas screensize (im sure u know this but havent done it due to the old bugbear time/effort)
good stuff humus, youre demos are about the only ones i bother downloading
one change u could make which will double the framerate at least i guess (it is a bit of extra work though)
after youve checked what cells are visable from your visability list
each frame use occlusion test (when u lay down depth pass) check if a light areas receiver/casters meshs are visable, itll save time by not creating unecessary SMs if they dont influence the scene
*another speedup is to use different size SMs based on a light areas screensize (im sure u know this but havent done it due to the old bugbear time/effort)
Sunday said:Good thinking
BTW
I love your new demo, and I’m curious is there some trivial explanation why are the PDM (Parallax Displacement Maps) are noticeable becoming flat on corners? Besides that little “dispelling†your PDM is great! Could be possible to sustain acceptable frame rate with little more complex levels, and that PDM of yours?
I’m asking this, ‘cos I think that PDM is equally important as say HDR, maybe even more IMHO! And I totally disagree with FutureMark guy in that interview where he’s trying to explain why they are excluded PDR from 3DM 06!
Are you referring to the fact that you don't see a proper silhuette? Then that's a flaw of parallax mapping as it's a texture space effect. You'd need real geometry to improve that.
zed said:
Right now I'm only using dynamic shadow maps for the rockets. The rest of the lights are static. So the gain would be small (most of the time the rockets will be visible anyway). If I used more dynamic lights there might have been a bigger gain. But even then I don't think it will be that much. It's possible to cull entire lights based on the visibility info too (but right now I only cull lights completely based on frustum).
zed said:
Good point. The question though is whether the difference between relying on the visibility info and extra accuracy of occlusion queries is big enough for me to be able to cut off a significant amount of lights. The number of lights drawn at any time is already pretty low, even before I've even implemented the full culling.
