Sunday, December 13, 2009

Just a quick update

Deferred Virtual Texture Shading

I've blogged about this idea before, using a virtual texture cache as a sort of g-buffer, and this has some advantages (I'm not going to re-iterate these again, just read my older posts if you want to know more).

Frankly it's simply a dynamic form of surface caching, so I decided I'll start calling this idea "dynamic surface caching" instead of "deferred virtual texture shading", which is a horrible name for it anyway.

Anyway, today I read a blog post about an idea where a light pre-pass renderer is implemented using spherical harmonics.
This made me realize that with my dynamic surface caching idea, the lighting of the surfaces could be stored as SH coefficients as well, de-coupling it from the view direction, which would make the cache idea more useful.

Realtime CSG

When I implemented the realtime CSG algorithm I've been blogging about, I was mainly concerned with getting it to work, getting it stable and making it perform fast, not so much with code readability (it was a prototype anyway).
Since I needed to explain it in a coherent way (or at least I try to) I needed to figure out all the peculiar details I put in code a year ago, and figure out how to communicate all this in an effective way.

This actually gave me some new insights and ideas.
My original implementation only had additive and subtractive brushes, no 'common' brushes, and the CSG operation was tied with the brush, making a complete CSG hierarchy impossible.

It worked really well for it's purpose (seriously, you probably wouldn't want to directly expose this kind of functionality in an editor anyway), but I have some ideas on how to generalize it, possibly make it more efficient, and definitely make it more readable and accessible.
So I need to do some tests and get some code working before I can continue with the blog posts about it.

Unfortunately this is a very busy time for me at the moment.
Clients with lot's of deadlines (meaning I need to do some work at home as well), a top secret project I'm working on with some friends of mine, preparing for Christmas, wife wanting me to do all kinds of home improvement stuff, and my daughter obviously wanting some attention between all this as well ..

But I should have more time to code around Christmas itself!


  1. reading your post i was thinking about some CSG method ... how about use rendering for it...
    like, for example stencil buffer , back - front planes etc .. serve tree of source objects and render it all. Maybe it will be expensive...

  2. It's possible to do this with the stencil buffer, but it'll be pretty expensive and cost *a lot* of fill-rate.
    Also, you wouldn't end up with a mesh, which is the entire idea of this exercise.. that you end up with a good quality mesh which you can then store, load in your engine (or what not) and render.

  3. Hi!
    Your idea is vey good. :)
    However, I think the specular component might not be of very good quality. In the case of a high exponent specular value, it could result in a very small specular reflection on the surface and if this reflection is smaller then the texel size, you will lose quality. But ok, this type of specular is may be not so often encountered.
    Anyway, this is something that have to be tested! :)

  4. Oh definitely, I'm not even completely convinced it's a good idea to do all the lighting in the virtual texture page cache because you lose all the benefits of screenspace algorithms. But hey, the only way to find out is to try it ;)

  5. Unfortunately SH is not suited for specular, that's the only view-dependent lighting anyway. I've also played with the screenspace SH idea. I don't think it works well.

  6. Can you elaborate? Why isn't SH suited for specular? Is the range a problem? Or the accuracy?


To you spammers out there:
Spam will be deleted before it shows up, so don't bother.