Saturday, January 10, 2009

Can you write Pixar ?

The first week of work after the holidays is over and I have some updates on RibTools, or I should say RibRender, because that's really what is becoming of it.

I finally implemented all the quadrics necessary to get the geometry of the Pixar.rib test file to render properly.
I also got another basic file (SimpleMug.rib) to render. It would need a disk primitive to be complete, but I'm just too lazy to implement something as simple right now !
Notice that the disk-looking shape is actually not a disk.. so where is the disk needed ? Not sure 8)

I started looking at other simple RIB files and I think that I'll be implementing patches next.
Also, up until now I've ignored the variable number of parameters concept that comes with more advanced RIB files. The parser itself expects a fixed number of parameters per command, but I should instead change the rule to a minimum number of parameters and ignore the extra parameters for now.

Incidentally, I'm also very busy at work !! There are some features I have to code in, and a lot of profiling and optimization that has been neglected for far too long.

It's a bit sad to think that I could probably get double the frame rate if only I had more time to optimize... but it's also important to avoid putting too much effort in custom optimizations. I can either do some clever DX 10 optimizations or I can play with RenderMan files and experiment with more innovative ways of rendering (the latter is something I do at home, but it will ultimately become useful for work, too).

It's so much easier to write code that doesn't require any particular optimizations.. now I'm at the point in which I really need to start thinking something clever for some specific cases.. though the overall result is already looking great.
In fact, we truly are getting close to off-line rendering at "interactive frame rate". However real-time is never really real-time.
Where does the pre-processing stop and interactive rendering start is a blurred concept. Real-time 3D is only possible because of some heavy pre-calculations.. be those some form of light baking, or even just batching together triangles with the same material, or resizing a texture...

Speaking of blurred concepts.. high quality motion blur and depth of field are still a problem.. especially motion blur, which is such a key element, one of those things that are somewhat subliminal and therefore getting less importance (at least in the real-time programming world).

mumble mumble

4 comments:

  1. Hmmm, what are the orange and green buttons on the window frame for?

    ReplyDelete
  2. Orange (yellow ?) is "minimize" and green is "maximize". Red is somehow disabled and it would be "close" anyway.

    It's a standard OS X window, which is actually created by GLUT.. I haven't actually bothered with OS X GUI programming yet (facking GUI programming !)

    ReplyDelete
  3. woo, nice progress!
    Maybe the disc primitive has just been used in that scene to put off people who want to implement a rib renderer! ;)

    About motion blur, it really looks like the more you have, the less framerate and AA you need, so it'd be great to see some advances in that area as well!

    ReplyDelete
  4. I don't think that one has much freedom to go below 30 fps.
    And yet, within that 30th of a second one has to somehow blur a moving object..

    The disk is the last straw !!

    ReplyDelete