Baking Plug-ins?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
Old 06 June 2006   #1
Baking Plug-ins?

Hello, gentlemen

Ramjac soft and Paralumino are working together with a new XP-based plug-in. All is going normally, but we've a problem: access to animation channels (same as XP-interchange and some other things) are restricted in Camera. Thus we are forced to discover solutions like: "let user run preview, the plug-in saves animated model in a file that will be "substituted" in Camera instead of usual plug-in's generate phase". Hmm... maybe it makes a sense to "bake" other plug-ins too (not only for our concrete task)?

Positives:

- fast render with saved file, avoid plug-ins re-calculation at each pass (bitmap shadows, glows, etc.)

- no problems with weight maps, XP etc. - all things are absent in Camera;

- portability - you can copy file to all your slaves - you don't need a plug-in itself if its result is baked


Negatives:

- numerous headaches with saved file (it can be really large)
- motion blur (maybe not always it can be provided adequately - we aren't sure)

Your opinion, gentlemen?
 
Old 06 June 2006   #2
It would seem with Camera's limitations, choice is not an option here. Perhaps we should be thinking of methods to ensure efficiency with the baking process and see if its even a viable solution. Personally, I think the idea of baking the plugin calculation and results is a fine idea provided its implmentation is effective and predictable. Particle systems like Dante, Fyreworks, and PPPro already use a somewhat similar approach. They can write out a cache of particles to assist Camera. From what I remember from Blair, Camera lacks the ability to look forward or backward in time thus a particle cache is needed.

Plug-in baking is definitely an acceptible solution in my book.
__________________
Brian J. Pohl

Previsualization Society - Founder / Secretary
Independent - Sr. Previs & Layout Supervisor
 
Old 06 June 2006   #3
One idea I completely missed the boat on is how NextLimit does fluid data. They have a file for every single frame of the animation and named with the frame number. Yes, there will be a ton of files but you're far less likely to run into 2 GB size limits.

The big problem with any plugin related scratch file is that Renderama knows nothing about it and wouldn't be able to automagically send them to the slaves.
 
Old 06 June 2006   #4
Hi, Brian
Originally Posted by Vizfizz: Particle systems like Dante, Fyreworks, and PPPro already use a somewhat similar approach. They can write out a cache of particles to assist Camera.
They should write cause particles need their "history", but it has nothing in common with baking.

Originally Posted by Vizfizz: From what I remember from Blair, Camera lacks the ability to look forward or backward in time thus a particle cache is needed.
Can't imagine such "Travelling in time" at render time
 
Old 06 June 2006   #5
I'm sure that a particle cache and baked plugin data is definitely two different things. I look at from the perspective that one type of system can do it, so why wouldn't baking plugins work too. Seems feasible to me.

My understanding on simulations is its important for them to have the ability to look forward and backward in time. My guess is for dynamic accuracy but I don't really know for certain. I'm not a programmer. Since camera can't do that, a particle cache must be generated.
__________________
Brian J. Pohl

Previsualization Society - Founder / Secretary
Independent - Sr. Previs & Layout Supervisor
 
Old 06 June 2006   #6
Hi, Brian
Originally Posted by Vizfizz: My understanding on simulations is its important for them to have the ability to look forward and backward in time. My guess is for dynamic accuracy but I don't really know for certain. I'm not a programmer. Since camera can't do that, a particle cache must be generated.
But, Brian, a common logic is absolute same for programmers and not programmers (last ones are only more familiar with concrete implementation details, nothing more). Imagine a render can see "past and future". Do you think it would be a big happy? Frame 5 asks frame 4, but frame 4 asks frame 5.. How it's called in English? Like "death embraces", right? And how many time frame 5 needs to repeat all generation process at frame 4? Yes, Camera (not camera) doesn't do this simply cause it's effective program
"Baking" looks an rational idea overview but we aren't sure in tech. details (especially this motion blur grr...)
 
Old 06 June 2006   #7
I think it's called an "infinite loop" in English. =)

I think Mental Ray works like that by examining the next frame (not sure about previous) in order to calculate the motion blur. I'm not sure about this but it seems logical as I don't know how you'd figure out how much blur to add. Again, I'm no programmer so take my words with a grain of salt.

I'm not familiar with the lineage but it appears to me that it's time that EITG opens up camera a bit more. Camera is a hot renderer, no doubt about it but there are some things that plugin developers should simply have access to in order make their cool plugins more robust.

I'm sure there's a lot I don't know about this issue but if you look at the success of a renderer like Mental Ray, one might argue it has a lot to do with how open it is. I think Camera is every bit as good as Mental Ray. I think it'd be in the best interest of EI to open up camera a bit.

Just my 2, uninformed cents. =)
 
Old 06 June 2006   #8
Baking here sounds like a sound solution, 'Running the preview' to save out the file already happens with the realflow plug-in. I can't think of any other way to do it.

So far as motion blur... Is there any need to look backward and forward in time?
When using Blaster you must render a minimum of two frames to get motion blur, perhaps something similar would be the case here.

The benefits seem to be rather large here, anyway there is only one way to find out
Ian
 
Old 06 June 2006   #9
Hi, Brian S., Ian
Originally Posted by sacslacker: I'm not familiar with the lineage but it appears to me that it's time that EITG opens up camera a bit more. Camera is a hot renderer, no doubt about it but there are some things that plugin developers should simply have access to in order make their cool plugins more robust.
We never shared an opinion "Camera should be opened"
In this concrete case (motion blur) we cannot blame our host in "not enough service/info".

A plug-in doesn't need to know how motion blur is drawn etc. For each vertex a plug-ins passes a "blur position" (vertex position at previuos frame) to host, it's all the render engine needs. Plug-ins are also informed about any object's motion, scaling etc, (all linear transformations). Thus in many cases the motion blur can be calculated very simple, as
blur_vertex_position = current_vertex_position * blur_transform_matrix
However, it doesn't work for plug-ins with mutable toplogy (like MrBlobby) and for skinned groups. In this case a plug-in needs to interpolate final blur position based on blur of its child groups. For example MrBlobby (btw: this plug-in is opened ) calculates blur as an average of blob's sources blurs. We see no way how to repeat/reproduce such blur with "baking"
 
Old 06 June 2006   #10
I know it's the wrong kind of baking, but I would be happy just for it to be possible to bake out shaders, GI & occlusion to UV maps. Can camera render to UV space or is there a way to automatically deform an object to it's UV's (like a morph)?

BB
 
Old 06 June 2006   #11
Hi, Brian B.
Originally Posted by bbuxton: I know it's the wrong kind of baking, but I would be happy just for it to be possible to bake out shaders, GI & occlusion to UV maps. Can camera render to UV space or is there a way to automatically deform an object to it's UV's (like a morph)?
AFAIK Camera cannot do this. However, IMO this baking isn't so attractive as it looks first. "Baking GI & occlusion" is exactly what radiosity does. Baking procedurals is problematic cause a lot of shaders are view-dependent. And any baking doesn't increase RT speed. So, what is a sense? "Make fast phong faster?"
 
Old 06 June 2006   #12
Baking comes in pretty handy with realtime engines. Not that I do much of that work asside from playing around though. Fancy MForge metal in a game engine... woo Hoo! =)
 
Old 06 June 2006   #13
Hello Igors,

occlusion baking to textures (and to normal maps) makes sense since the renderer does not need to render the occusion for static objects again and again each frame. Its not about making phong faster, but to substitute long raytracing rendertimes with short phong render times. Its not only good for realtime purposes, but also for architectural renders, and environments in general.

The benefit of baking to textures in opposit to radiosity is, that radiosity needs many polygons and subdevisions to store the shading within the vertext colors of the object. If you have a simple cube you have six (12) polygons. If you bake to a texture you have still 6 polygons and a texture that stores all the subtle shading information an occlusion pass usually provides. if you use radiosity instead you increase polycont by a factor of some hundrets more polygons.

This may not sound like a real problem for a simple cube, but when it comes to detailed architetural models it can be a problem since the benfit of the baking is eaten up by the increased numbers of polygons to be rendered.

A general benefit of texture baking is, that the textur can store far more shading infomation. It is possible to bake detailed maps containing all details of the original model which can later be substituted with a low poly version of th same moel - the render will look identical but take only a fraction of rendertime compared to the raytraced original model.

Is all about render efficiency.

-------------

Baking (as initially asked for in this thread) of models to a rendering database is somthing I personally really do not like due to the fact, that it is very timeconsuming to use on large scale projects, since the distribution of the cache file to renderslaves only works manually. It gives major headaches when you want to change things in your setup fast.

I have not a solution for this but this is the reason I do not wok with particle plugins in EI anymore and rather like to do them in After Effects or somwhere else.

Jens
__________________
Jens C. Möller
JCM Animation/ramjac Software
 
Old 06 June 2006   #14
with most of the major 3rd party developers and even Matt Hoffmann visting CGTalk from time to time, let me ask you:

is it really not possible to teach renderama to distribute plugin cache data?
why does it have to sit in the socket folder?

as a non-developer i imaging there is only a path variable to be passed on (and modified for the slaves).
like so:

- plugin tells EIAS that it has cache data and where to find it
- EIAS saves this information into the project file and tells renderama
- renderama copies these files over to the slaves and changes the path to the slaves temp folder

there is probably more info to be passed over like timestamps to catch changes and so on, but the situation right now is pretty oldschool, if you know what i mean.
i like my socket folder to stay clean and not cluttered with project specific files.
__________________
http://www.orangefx.de
 
Old 06 June 2006   #15
Hi, Brian S.
Originally Posted by sacslacker: Baking comes in pretty handy with realtime engines. Not that I do much of that work asside from playing around though. Fancy MForge metal in a game engine... woo Hoo! =)
Sorry, but MF is unlucky example. Anisotropic (speculars) cannot be baked. Same as MF's reflections and others view-dependent gradients. Thus effect of "MF baking" would be a little only
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 12:50 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.