• Tom S (12/12) Jan 18 2008 Heya! I've written a short note about a 3d software rasterizer I've
• Bill Baxter (7/15) Jan 18 2008 Nice! Is there an API or do you have to create a model file to render
• Tom S (12/17) Jan 19 2008 Currently it can only render to the screen... It doesn't have a very
• janderson (17/28) Jan 18 2008 This is some nice work. It seems to run a little slow. I assume this
• Tom S (22/40) Jan 19 2008 It's a very basic renderer, with not many optimizations, but I believe
• janderson (26/44) Jan 19 2008 believe it's not very slow either, at least for something not using any
• Tom S (6/9) Jan 19 2008 Thanks!

Tom S <h3r3tic remove.mat.uni.torun.pl> writes:

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

Bill Baxter <dnewsgroup billbaxter.com> writes:

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 <h3r3tic remove.mat.uni.torun.pl> writes:

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 <askme me.com> writes:

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.

Tom S <h3r3tic remove.mat.uni.torun.pl> writes:

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

janderson <askme me.com> writes:

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

Tom S <h3r3tic remove.mat.uni.torun.pl> writes:

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