WIP 3D Engine (Update : v0.07 screenie preview) [v0.06]

[hellfire]

If I turn on the fpu option when compiling the examples, will they run on most/every machines ?

It won't run on anything older than Pentium3 (1999) or AthlonXP (2001).
A benefit of using SSE for floating-point operations is that MMX (which shares its registers with the fpu) can be used for pixel-processing.

[DruggedBunny]

I don't have anything useful to offer, but this is a fascinating thread, and you're doing a fantastic job with the advice of these experts, Hezad! It's hard to see many practical reasons for software rendering these days, but I still find it fascinating, and I have tons of respect for people who implement it. I also love the visual idiosyncracies that software rendering can offer over standard DirectX/OpenGL rendering. All games should look like Zeewolf! http://amiga.probers.info/images/stories/predseda/zeewolf205.gif

I do think (well, I hope) that Intel's Larrabee (and the competition's resulting efforts) will offer a genuine avenue for such in-depth software rendering knowledge in the future:

http://arstechnica.com/articles/paedia/gpu-sweeney-interview.ars
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367&p=1

You will be one of the very few people in the world who are able to take advantage of such arcane knowledge!

[Hezad]

@hellfire : oh yeah okay, thanks I'll make a fpu and a "non-fpu" compilations of examples for the next release


@DruggedBunny : Heya thanks a lot for your kind words. These papers are very interesting

[Hezad]

A little screen from the v0.07 in progress The fake phong shader has been improved !

[Shockwave]

Very shiny! the shapes look like they are more solid now.

[Hezad]

the shapes look like they are more solid now.

Yep The way I "add" (specular) and (diffuse + ambiant + texture data) is not perfect though, I must work on it, but it's a first step

[hellfire]

That looks great, Hezad! Now all that's missing are shadows

[Shockwave]

That looks great, Hezad! Now all that's missing are shadows

I suspect that Hezad will try them soon... He's run out of other things to add to the engine now I think.

[Hezad]

That looks great, Hezad! Now all that's missing are shadows Grin

That looks great, Hezad! Now all that's missing are shadows Grin


I suspect that Hezad will try them soon... He's run out of other things to add to the engine now I think.

uhuhuh thanks In fact I still have optimizations to code :S but yeah, shadows are already planned ^^ Just don't know when yet.
However, there're still a lot of cool 3D "concepts" I'd like to add :p

(not in any order)

• Env. Mapping
• real phong
• Shadows (of course :p)
• dynamic (in an utopic world static otherwise) ambient occlusion
• reflexion/refraction (so raytracing, and scene handling)
• other stuff I'm not thinking about right now ...

I already red several articles/tuts/... about those different steps and I get them roughly but I just don't really know what to code next. Of course some stuff are way more difficult to handle than others ...

I'll start with a question about shadows if you don't mind ^^

Can I really envisage to add dynamic shadows in real-time in a software 3d engine without loosing a huge amount of FPS ? Obviously without using 'cpu-costly' shaders (using Gouraud shader max no phong or fake phong)

[Shockwave]

Do you want objects to be able to cast shadows upon other objects and themselves or are you looking to simply project a shadow onto a plane?

Probably the method you want to impliment is shadow volumes.
For each light source you have, you need to project a ray from the light source, passing through every vertex in the object you are testing to some point outside your scene (infinity). You can then test the vertices in your scene to see if they lie inside the shadow volume, if they do then they are in shadow and you can colour accordingly.

This would work quite nicely for you without too much cost.

[Hezad]

Yeah, I'd like the objects to cast shadows on other objects and themselves

I red some stuff about shadow volumes too.

This would work quite nicely for you without too much cost.

I'll give it a try then

[Stonemonkey]

Hi hezad, nice work you've done on this. Stencil shadows (volumes) are definitely do-able in software although you'd probably be best to try to keep the number of large shadow casting objects to a minimum and in some cases you can simplify the shadow casting geometry but it can lead to some problems particularly with self shadowing objects.

A couple of things I would recommend looking up are sillouette edges and z-fail, using z-pass doesn't work well if the camera is inside a shadow volume.

Since the technique needs at least a depth pass of the scene initially I did my texturing and shading interpolation in that pass also but instead of doing the shading calcs I stored the colour as 24 bit and the shading as 8 bit (I came up with a bit of a dodgy method of storing the diffuse and specular in 8 bits).
Then filled the shadow volumes, front facing triangles increment the value in the stencil buffer if the z test fails and backfacing triangles decrement the value if z test fails.
Then in a single pass over the screenbuffer did my shading calcs for each pixel using the values in the stencil buffer to determine whether the pixel was in light or shadow.
I could never get this to work with anything transparent.

One way to add simple planar reflections for example to the floor is to make the floor transparent and place an inverted copy of your scene underneath.

[hellfire]

Shadow-volumes are a serious fillrate-killer and since you need a z-pass anyway, you're sometimes better off with zbuffer-shadows. Both techniques have their pros & cons, though.

[Hezad]

thanks for your advices, I'm still checking a lot of ressources on the net about it to understand the vocabulary and the different algorithms
In the same time i'm pretty interested by Occlusion culling So i'm thinking about a way to use both shadows and occlusion culling in the same time, that'd be bloody awesome

[Stonemonkey]

Even though shadow volumes suffer from hard edges I still prefer that over the aliasing of other methods and as I said it's possible to do it in a single pass of the scene so the impact on using shadows only depends on how many objects are actually casting shadows and what size they are, too many or too large and yep, fillrate becomes a problem. Still, it's all down to personal preference and some methods might be preferable depending on the application.

Here's a small example done in freebasic I've dug out, sorry I can't find much else atm.

[Hezad]

heya thanks for the exe !! it's pretty attractive ^^

[Shockwave]

Oooh, I hadn't seen that example before Stonemonkey.
It runs at a very good framerate.

[hellfire]

shadow volumes suffer from hard edges

That's not so much of problem when several light-sources are blending together (have a look here, it's accelerated though).
Distance attenuation makes the hard edges less obvious and near to a light-source shadow-edges are pretty hard anyway.
But a proper lighting-rig that doesn't look totally synthetic requires a considerable amount of light-sources; not all lights require shadow-casting though, but one is quickly multiplying fillrate to unreasonable amounts (especially when filling in software), not to mention enabling multisampling to make the hard edges a bit softer.
I haven't yet managed to integrate shadow-volumes with envmap-based lighting authentically.
Shadow-maps on the contrary have one major benefit: You can look up a pixel's surrounding in the map and decide the amount of shadowing without much cost.
Still both methods are useful to have.

[Stonemonkey]

Ah very nice hellfire, I'd done some stuff with multiple lightsources and volume shadows in hardware too but it might be a bit too much work to get out of software rendering.

I'd also looked into shadow maps but never attempted it as it still looked to me like a lot of additional work, particularly for dynamic shadows.

Shadow-maps on the contrary have one major benefit: You can look up a pixel's surrounding in the map and decide the amount of shadowing without much cost.

even with software? I've been trying bi linear filtering which costs a little over nearest pixel but to add more interpolation as well as multiple lookups from the z buffer and then calcs to work out the shadow value could add a fair bit.

[hellfire]

it might be a bit too much work to get out of software rendering

For the beginning you can keep the software-engine as it is and just call "someone else's" polyfiller.
On the long run it's inevitable to rearrange most of the data-structure, though.
It can be quite deflating to see how much faster that damn hardware is in comparism to a seemingly well-optimized software-polyfiller...

shadow maps [...] looked to me like a lot of additional work

Since you need to draw a z-pass from the light's point of view, it requires some sensible concept to use a framebuffer's zbuffer as a texture without making the renderloop a complete mess.
Unluckily inheritance isn't implemented in FreeBasic yet, so I can't really suggest an aesthetic solution here.

look up a pixel's surrounding...

to add more interpolation as well as multiple lookups from the z buffer and then calcs to work out the shadow value could add a fair bit.

For hard-edged shadows you'd test if the current pixel's distance from the light is greater than the distance stored in the shadowmap, so it's a simple compare (to avoid the compare it's even just the sign-bit of the difference). Usually the z-values can be stored with enough precision in 16bits, so a 2x2 area only requires reading of two dwords. There's no interpolation required here, you just count how many samples are lit. Creating a few levels of mipmaps from the shadowmap can increase the sampling area without much cost.
To avoid out-of-range tests when accessing the shadowmap in the innerloop, I clipped all polygons at the borders of the shadowmap.