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

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

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.

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

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 :F


> Oh, 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

Tom S wrote:
> 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.

That's a good idea.

> I failed the 'Abstract Algebra' exam and had to study to take it again, thus shrinking my predicted time budget :F
>

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 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 :)
>

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

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