Monday, February 1, 2010

Displacement, etc.

As I kept silent in the blog, a few important advances were made in RibTools !

I've finally got the Killeroo model to render with displacement mapping. This involved implementing and fixing a few things:
  • Implementing NURBS
  • Implementing some sort of image library to handle bitmaps with flexible formats
  • Fixing a few things in the shader system, including normal recalculation.. necessary to recalculate normals of the samples that were perturbed by displacement
  • Texture sampling with bilinear filtering (critical for displacement mapping)
  • Handling the "Display" directive in RIB files to output to either a file, with a specified name, or the framebuffer
  • Linking libtiff to handle TIFF files
  • Updating ribtools.com
Quite a bit of work indeed !

Stuff like the Display command, are not as interesting, but are important if one aims at being "RenderMan compliant".. if anything to be able to render the same RIB files as other renderers, to compare the results.

The update of ribtools.com was actually a pretty substantial one !
I went from Google Sites, the wiki-like WYSIWYG system to MediaWiki.
MediaWiki is famous for running Wikipedia, it's really powerful, well tested and supported.. however it's not as easy to setup and tweak (settings are in a PHP file !).
It's pretty crude, but it's better than some other wikis out there that usually have some annoying restrictions or general lack of support because the community behind isn't as big.

Google Sites is still a lot easier to manage than MediaWiki, but the initial simplicity becomes a burden once one needs to do some more serious writing and documenting.

I mentioned this before but... let me reiterate that Google Sites' WYSIWYG is terrible. Its internal state gets really messed up, and one then has to go and manually edit the HTML. However the HTML produced by Google Sites is ugly and bloated as sin.. it's not mean to be hand-edited and it shows.
So, at the end of the day, the wiki markup of MediaWiki is much more convenient.

For documenting, there is a certain need to write repetitive things, use tables (completely broken in Google Sites), also edit directly only a portion of a page (MediaWiki has convenient edit links at each major heading to edit only that portion of a page (until the next big heading)).
One example is the List of operators of the shader VM. It takes the form of an operator in a line and the description in the next line.
Using a plain text editor, in wiki markup this becomes:

;instruction
:description


';' will make the text bold and ':' indents the text.
It's a markup meant to document things and it can be quickly edited with a plain text editor, without having to go and manually select words, make them bold, indent lines and fight with the styles that spread in neighboring text and generate a lot of messy and redundant HTML code.

Speaking of the wiki, I've also written some sort of FAQ about the project and REYES (or Reyes 8) in general.
I'll need to rewrite things more clearly and include some pretty pictures..  because plain English explanation is probably too dull to follow.
I'll add images at some point but, for the time being, I think that the site is already taking enough effort away from the programming tasks 8)

zzzzzzzzzz

8 comments:

  1. Wow, good advances! I have been following silently during the last months...
    Good job on the wiki too!
    Claudio

    ReplyDelete
  2. Thanksss !!

    Still a long way to go.. but it was important to get at least the basics down 8)

    In the immediate future I think I'll actually put down some sort of presentation to better explain what I have in mind..
    Entering the new year, new opportunities may be presenting themselves and I want to be ready to get some attention from above 8)
    (Please God, support my renderer !)

    ReplyDelete
  3. Hmm ... need to do a source code update ... 8P Maybe I should port it to the Mac for you. ;-)

    ReplyDelete
  4. Mr. Ragin,

    A Mac port would be great.. the code is fairly quite portable.

    The main issue is the project files.. I was thinking to move to something like CMake or premake (I read about some frustrations with CMake).

    Then there is the multi-threading.. that uses Window's CreateThread and Critical Sections ..but it's very limited and should be easily ported to pthread (nothing is easy !).

    woooooooooo

    ReplyDelete
  5. Micropoly-master Kaz,

    I'll compile the Windows version to see where things are at. I've been meaning to get back into OS X programming ... things seem to be basically Objective-C only now ... so maybe a port will give me some good practice before I scramble my brains with this strange hybrid of a programming language. 8P I'll keep you posted.

    ReplyDelete
  6. Actually.. Objective-C is only a superset of C/C++ ..so all C++ should work untouched.

    As far as I understood, it's only the collating code with the API and tools that may need to be Obj-C ..however RibTools right now has little GUI and it's all based on GLUT.

    Remember that I started RibTools on OS X indeed and only moved to PC because XCode visual debugger sucked and there was no C++ refactoring 8)

    ..but one can still hope !

    ReplyDelete
  7. From the last time I looked, one can only create native Objective-C applications now. You can still do all the C/C++ to Objective-C hooks though. I wasn't too happy when I found this out when trying to port over my framework from Windows to OS X ... was making good progress too. :(

    I haven't looked, but there should be a way use GLUT with Objective-C.

    ReplyDelete
  8. Bhaaa !
    I can't stand proprietary solutions.. APIs, support of languages that nobody really wants.. etc..

    ReplyDelete