Program design question regarding Pixie...
Status: Beta
Brought to you by:
render_man
Menu
▾
▴
I am programming entirely procedural animations against Pixie's lib. So as I go, I'm trying to build a library of handy objects. For example, I have already written simple class wrappers around all the quadrics. Pretty easy I know. Before I get too deep into building this library, I'm realizing that the routines to draw this primitives could be done several ways. My main focus is photorealistic rendering, but I'm thinking it'd be handy to be able to preview things in realtime as I go along. So, in the future, I might want to the quadrics to draw to an OpenGL window as well -- even if it's just bounding boxes. I'd like to get some feedback as to pros and cons.
Option1: Pixie centric.
This is the simplest and most immediate approach (at least on the surface). With this approach, each primitive might have a member function called something like RiDrawSphere() which would basically translate private data members for radius, position, etc. to RiTokes or parameters. Seems like that's not rocket science. However, down the line, as real-time quick previews would be nice. Would this design make that a bear? It seems that I'd have to create another drawing method for each -- something like OGLDrawSphere(). You probably get the idea.
Option2: OpenGL centric.
With this option. I'd create a simple set of tools to render my objects in real-time. Then, I'd figure out how to map that system to Pixie lib. You probably get this one too.
Option3: Fast Pixie?
With this design, it would be 100% Pixie. I'm not sure of the performance characteristics of the different hiders so I don't even know if this is viable. The basic idea is that I create (overtime) my library without real-time preview. Instead, I'd create highly optimized settings for display -- aliased, down and dirty, low-res, turn off surfaces, substitute lights, etc. Whatever it takes to make Pixie FAST. Then, write a driver to collect output into a multi-frame playback display. I'm no code guru, but I'm sure there's a lot of stuff out there (including OS dependent - yuck) to mangle to my needs. This design would require the least of me -- which is nice. I like making images!
Anyway, to recap:
1. OpenGL over Pixie
2. Pixie over OpenGL
3. 100% Pixie, plus custom display driver
Love some input.
I guess it depends what kind of geometric shapes you envisage rendering.
I think I'd be tempted to do the following:
create a base class for your objects, with a a render() function or similar.
create a base class to represent a renderer, with a set of functions that will allow you to feed through the type of geometry you're going to have to deal with
Specialize a given renderer type from your renderer base class (doing the appropriate conversions to RI calls or OpenGL or whatever).
Be aware that certain RI geometric types won't map nicely onto OpenGL calls - SubD's at least spring to mind. You also won't be able to get displacements etc. working easily. But it depends what you want. If you're simply after a rough representation of what might be in the final render, it'll do the job.
Each object's render() function knows a bit about the geometry it's likely to contain and will talk to the renderer class through the defined base-class interface.
Then you only have one interface to any render to worry about. You can then store the data in your object classes as makes sense for your simulation.
A new display driver probably won't win you enough to get real-time performance (defined these days it seems at at least 10fps, but probably 30fps or higher for smooth looking playback).
Just an idea.
George
George. Good stuff. Yeah, I wasn't planning on rendering anything super fancy in OpenGL. I have looked at it's implementation of subd's and it seems very open ended with little support for the programmer. I have found a few net resources on visualizing subs in OpenGL. I was considering keeping it simple though -- for example just rendering the control hull on a patch, etc. So OpenGL could work fine.
I'm not looking to get a WYSIWIG display at all. More for quickly checking positioning, speed, etc. Just a down and dirty preview. So I wouldn't worry about surfaces, etc. Probably just generic lights, matte surfaces -- very minimalist.
That said, what if they two were combined? Since I'm going to have to create an OpenGL drawing context, I could add a display driver so that you could pause the OpenGL preview and render with Pixie, or even just a selection if the current frame. Could be a cool tool. If it's just for me I can make something ugly that works. However, do you think this is something that the community would enjoy? Are there many programming directly against Pixie? If so, I could clean it up a little with an idea of releasing it. Whatcha think?