digitalmars.D.announce - DShade - a 3d software rasterizer
- Tom S <h3r3tic remove.mat.uni.torun.pl> Jan 18 2008
- Bill Baxter <dnewsgroup billbaxter.com> Jan 18 2008
- Tom S <h3r3tic remove.mat.uni.torun.pl> Jan 19 2008
- janderson <askme me.com> Jan 18 2008
- Tom S <h3r3tic remove.mat.uni.torun.pl> Jan 19 2008
- janderson <askme me.com> Jan 19 2008
- Tom S <h3r3tic remove.mat.uni.torun.pl> Jan 19 2008
Heya! I've written a short note about a 3d software rasterizer I've programmed in D some time ago as a final project for my "Graphics and Multimedia" course. You can read about it on my freshly created devlog: http://h3.team0xf.com/devlog/?p=5 Sorry for not posting about it before; I've had weird issues with DShade crashing, but they have magically disappeared with the recent DMD and Phobos ( so I'll pretend the issues don't exist anymore :P ). Cheers! -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jan 18 2008
Tom S wrote:Heya! I've written a short note about a 3d software rasterizer I've programmed in D some time ago as a final project for my "Graphics and Multimedia" course. You can read about it on my freshly created devlog: http://h3.team0xf.com/devlog/?p=5 Sorry for not posting about it before; I've had weird issues with DShade crashing, but they have magically disappeared with the recent DMD and Phobos ( so I'll pretend the issues don't exist anymore :P ).
Nice! Is there an API or do you have to create a model file to render anything? With an API and the ability to render to a buffer you have a neat way to render small textures in the background using just CPU power. Probably going to be many nifty things you can do with that over the next few years as #of procs increases. --bb
Jan 18 2008
Tom S <h3r3tic remove.mat.uni.torun.pl> Bill Baxter wrote:Nice! Is there an API or do you have to create a model file to render anything? With an API and the ability to render to a buffer you have a neat way to render small textures in the background using just CPU power. Probably going to be many nifty things you can do with that over the next few years as #of procs increases.
Currently it can only render to the screen... It doesn't have a very engine-like API. Here's an excerpt from the init() function: http://paste.dprogramming.com/dps0ik1d The Framebuffer class could be replaced, so that it's not double-buffering to SDL but giving textures instead; a new Node class could be created as well, Then any other model format / data source might be used, I guess :) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jan 19 2008
Tom S wrote:Heya! I've written a short note about a 3d software rasterizer I've programmed in D some time ago as a final project for my "Graphics and Multimedia" course. You can read about it on my freshly created devlog: http://h3.team0xf.com/devlog/?p=5 Sorry for not posting about it before; I've had weird issues with DShade crashing, but they have magically disappeared with the recent DMD and Phobos ( so I'll pretend the issues don't exist anymore :P ). Cheers!
This is some nice work. It seems to run a little slow. I assume this is software rendered so I guess performance is reasonable for that. Anyway I'm not trying to be picky, but if you don't mind here are some optimisation suggestions. I couldn't look over all your code so I may have missed something. Are you using the PVS data stored in the tree to speed things up? Are you sorting closest to furthest so that you can early out in your z-tests (the BSP tree almost does this for you). Another thing you could do is a software occlusion test using the bounding boxes of the BSP nodes. Oh, another probably obvious: make sure your not doing any allocation during the real time part of the game. My thesis may be helpful. The engine was in D, however it uses hardware rendering and doesn't look half as cool as yours. http://www.gamasutra.com/features/20060417/anderson_01.shtml Anyway, nice work.
Jan 18 2008
janderson wrote:This is some nice work. It seems to run a little slow. I assume this is software rendered so I guess performance is reasonable for that.
It's a very basic renderer, with not many optimizations, but I believe it's not very slow either, at least for something not using any SIMD instructions and done in about two weeks.Anyway I'm not trying to be picky, but if you don't mind here are some optimisation suggestions. I couldn't look over all your code so I may have missed something.
I don't mind, thanks :)Are you using the PVS data stored in the tree to speed things up? Are you sorting closest to furthest so that you can early out in your z-tests (the BSP tree almost does this for you). Another thing you could do is a software occlusion test using the bounding boxes of the BSP nodes.
Unfortunately nope, I didn't have enough time to do that. I guess I'll add this stuff when I'm bored (and find some spare time) ... I actually wanted DShade to do span-based rendering like in the old times. That would provide pretty decent occlussion testing, but... reality struck. I failed the 'Abstract Algebra' exam and had to study to take it again, thus shrinking my predicted time budget :FOh, another probably obvious: make sure your not doing any allocation during the real time part of the game.
Sure thing :) I only use the GC for top-level objects, malloc elsewhere, there's some pooling going on under the hood as well.My thesis may be helpful. The engine was in D, however it uses hardware rendering and doesn't look half as cool as yours. http://www.gamasutra.com/features/20060417/anderson_01.shtml
I've actually had it on my HDD for a while. Hard not to notice a gamasutra feature by a fellow D (game) programmer, especially when it touches BSP trees ( when every other kid was playing with early hardware shaders, I stuck my nose in automatic portal generation ). Your thesis may come in handy when we restart the work on Deadlock :) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jan 19 2008
Tom S wrote:janderson wrote:This is some nice work. It seems to run a little slow. I assume
It's a very basic renderer, with not many optimizations, but I
SIMD instructions and done in about two weeks.Anyway I'm not trying to be picky, but if you don't mind here are
may have missed something.I don't mind, thanks :)Are you using the PVS data stored in the tree to speed things up? Are you sorting closest to furthest so that you can early out in
Another thing you could do is a software occlusion test using the
Unfortunately nope, I didn't have enough time to do that. I guess
actually wanted DShade to do span-based rendering like in the old times. That would provide pretty decent occlussion testing, but... reality struck. That's a good idea.I failed the 'Abstract Algebra' exam and had to study to take it
Hay, I completely understand. It looks like you've already put a huge amount of time into this engine.Oh, another probably obvious: make sure your not doing any
Sure thing :) I only use the GC for top-level objects, malloc
My thesis may be helpful. The engine was in D, however it uses
http://www.gamasutra.com/features/20060417/anderson_01.shtml
I've actually had it on my HDD for a while. Hard not to notice a
touches BSP trees ( when every other kid was playing with early hardware shaders, I stuck my nose in automatic portal generation ). Your thesis may come in handy when we restart the work on Deadlock :)
Nice to know its using someones MBs :) If you do decide to use it, feel free to email me any questions you have. I think you may already have my email however here it is again: its hohums on google's email. -Joel
Jan 19 2008
janderson wrote:Nice to know its using someones MBs :) If you do decide to use it, feel free to email me any questions you have. I think you may already have my email however here it is again: its hohums on google's email.
Thanks! -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jan 19 2008