Baking Plug-ins?


#45

Something like this?

http://homepage.mac.com/groothuis/modo/animatedlight.mov

For me this thread is about possibilities, I like EIAS GI it’s very good, and very usable in production! The GI rendering is one of the best things added to EIAS the last few years
My complaints about splotchy animation renders is a general GI problem, all applications I have seen so-far have this problem.

(Although Vray has an interesting approach to this problem http://www.spot3d.com/vray/help/VRayHelp150beta/tutorials_imap2.htm but I don’t use MAX)

Cheers

Hans


#46

Although my experience at ILM was primarily in previsualization, I did spend a month or two working on THX-1138. For this show I was required to create a complete final shot from start to finish. I could use any tools I wanted. I wanted to stretch myself a bit so I used Maya and a lot of ILM’s proprietary tools. I’ve attached a snapshot of the scene. The LUT is all out of whack in this snapshot, so it might look a little weird, but you get the idea.

The concept of baking occlusion lighting is used all the time in the Matte Painting department at ILM. A single high resolution ambient occlusion or GI still frame is generated and composited into the scene using any number of compositing packages. For most applications, a single frame was enough. If there was a slight need for camera movement a camera map could be implemented. It was combined with a diffuse, reflection, reflection occlusion, and specularity pass. Other passes were used if called for. It was ILM that got EI to include reflection occlusion, shadow masks and render passes into EI in the first place, but back then there was no ambient occlusion / GI capabilties in EI. They used the equivalent of a manually generated illuminator back then to create “fake” ambient occlusions. If I remember right, they called it a “Bee Hive” lighting rig. This of course worked well for lock offs and cg generated background plates and thanks to EI’s speed, fake animated ambient occlusions were possible. Generating a true animated GI pass / ambient occlusion that will accomodate for lighting shifts is considerably more expensive. So, the ability to bake the GI pass would add a tremendous speed advantage but at a major cost as well.

The ILM philosophy is to have as much control over the appearance of the scene as possible. Although we created a GI pass, it was never baked into the textures/geometry. We were trained to break everything out into a separate render passes…and I mean everything. Some of my after effects comps were hundreds of layers deep. Kinda crazy. But you know, it came in handy when the director wanted to pixel f*@$ your scene. However, for the average user, a baked GI pass could be a boon.

I sometimes wonder if the reason why EI doesn’t have lighting/texture baking is because of EIAS’ lack of a decent UV editing system. If we were to ever get that implimented by the host, I think this sort of thing would become a reality much faster.


#47

Same as all you said is a true too. Yes, “I can fly” (practically in real time) is a really cool feature, but, Jens, an user should be informed well and exactly about “how much” it “costs” in view of pre-calculating time and efforts - otherwise, sorry, Jens, but it’s an irresponsible promising of “communism tomorrow” - we’ve seen a lot of such ones.

If you ask what feature should be first for EI (if we understand you well) then we can answer: multi-layered rendering and post-processing system. That’s our opinion


#48

Hi, Uwe

Uwe, you are not who shares an approach “ich (aux verb we don’t remember) klein mann” :slight_smile:


#49

Hi, Brian

Average user (same as advanced one) can do this with radiosity from 5.0. Hmm… but it’s really amazed how attractive is an old thing in a new bright envelope :slight_smile:


#50

The problem with the radiosity engine since EI 5.0 is, that it never worked well.

Agreed.

Jens


#51

Hi, Jens

We aren’t radiosity fans/specialists thus we cannot judge. But, Jens, look at “occlusion baking” you are excited with:

  • enough long pre-calculating phase;

  • topology problems (visible dges etc.);

  • huge amount of data (btw: much more with textures);

  • far perspective of almost momentary render (“twenty years of persistent labor, thousand years of happy” - hmm… people (count us) need a little happy but now)

Is all correct? If so the list above is a classic description of radiosity as it’s known recent 5 years. Maybe Modo discovered a new, more friendly, radiosity? Maybe, that’s we don’t know. But in any case their marketing is genius (and 100% correct). Of course, you can name it as “occlusion baking” (a new revolutionary appraoach - Alonzo, where are you? :wink: You can even name a cat as a cow. But such “cow” still says “mhau” and gives no milk :slight_smile:


#52

You do not like baking.

I like it.

I guess that is clear by now.

Lets move on to a more productive topic, shall we?

Jens


#53

You’re not alone, every major 3D application supports this feature in some form :wink:
I just never realized it could be so effective on interior scenes, … and such a time saver!

Maybe multi-layered rendering?

Cheers

Hans


#54

Hi, Jens

Not we started this aspect as it’s clear from this thread begin. But if it happened, let us note: the thing you like (as you just said) and the thing you don’t like (radiosity) are …same things in fact :slight_smile:

Sure! BTW: waiting for last XP-server changes, help


#55

Hi, Hans

Sorry, Hans, we’ve nothing to say instead of annoyed “it should be in host” :sad: So, it’s just “our dream”

BTW: we would be interested in details about SSS in Modo. Your little explanation/images would be wanted. Of course, no probs if you’ve no time


#56

Maybe its the same thing, but I have never worked with a workable radiosity engine but my experience with baking is good so far.

Did Patrick give you a date for a new build? I have contacted him to see whats up with it.

Jens


#57

For the Igors, this thread has drifted off topic.

Did you ever get an answer to the possibility of baking out particle data in a preview run?


#58

Hi, Kurt

Initially we proposed a “baking” for all “capricious” plug-ins that, for example, repeat their calculations, a bit slow, have some problems in Camera etc. - say shorter, just “calculate once” for plug-ins. Yes, for particles too (just final particles are baked, not their database)


#59

Hey Igors, Jens, Uwe, Hans, Brian…

I’m really liking these Cgtalk chats… but Im really busy and crazy trying to finish my FIAT job.
Playing with Maya I found they love to use baking data, Shave and Hair Cut (hair and models instance), Syflex (Cloth and Skin)… Applications like RealFlow does too.
A long time ago Kishore helped me doing a script to export Maya animations in Obj format to be read in EIAS using (OBJ2FACT, Thanks Jens) and with the new cycling feature be used in EIAS… but EIAS need to read all sequences in the Host, right?
so, I always asked myself… why EIAS cant read data from the Hard Disk? Now we have G5s, Pentiums, fast HDs… and Animator will have more memory to work.
Its the same for baked Data, I guess.
If a plug-in does all math, and you dont change anymore any channel… why It dont read the data in the HD?
How Morphing targets work? How animator store each target? or it acess each target in each frame?
If Animator read always 3 frames in the current position of the time in the animation’s Data from the HD it understand always the Motion Blur and the view port preview, correct?
I agree some positions… like Rama need to make the Data Distribution to us in the renderfarm.
I have 30 machines here… its impossible to make it by hand without a mistake.

And Changing the issue of course… like I love to do.
I Like GI and Textures Baking like all other users here.
I remmebered When J. Banta showed me How ILM baked all GI using the LightWave plug-in to render in EIAS in the Pear Harbor feauture Film… its a really interesting and pipeline aproved tool.
I know… like Igors always says, have good and bad issues in all techs.
But I pretty sure that all users here knows about the prbs in Textures and GI…like poor quality in Zoom ins… but with some tricks like creeate a second map to only the area which you will zoom in… this GI map or Texture map… will make our Camera’s render really Fly.
I liked How Modo does… lets test more Modo and see How it works.
But Igors, think a bit more… is it not interesting How many Pro users are asking it?
I remebered when I bought my first EIAS version and asked Matt Hoffman… Matt, is it not possible to add a feature which you flatten all the textures (like Photoshop) in only one texture to render faster? without know anything about 3d… which means bake Textures… and in that time Bake wasnt created yet in 3d.

Thankssss

Tomas


#60

Hi, Tomas

Know-know :slight_smile: BTW: your letters would be very easy to recognize even without “sssss” and “Tomas” - that’s your style to discuss 10-15 themes same time :slight_smile: As always, we ask you to be more concrete and we would be happy to answer all we know for all your Q


#61

Haha,

Like you know, I’m a multi core brain.

Ok, lets start with Baking Data to plugins:
why EIAS cant read data from the Hard Disk? Now we have G5s, Pentiums, fast HDs… and Animator will have more memory to work.
Its the same for baked Data, I guess.
If a plug-in does all math, and you dont change anymore any channel… why It dont read the data in the HD?
How Morphing targets work? How animator store each target? or it acess each target in each frame?
If Animator read always 3 frames in the current position of the time in the animation’s Data from the HD it understand always the Motion Blur and the view port preview, correct?
I agree some positions… like Rama need to make the Baked Data Distribution to us in the renderfarm.
I have 30 machines here… its impossible to make it by hand without a mistake.

Thanks
Tom (Dual Core Brain)


#62

Hi, Tomas

Eventual reading data from HD doesn’t reduce their size - Animator will have same amount of memory

We guess you talk about “common caching”. But, unlike other caching applications/usage, it’s not a rational idea to cache all generated geometry at each frame. For example, a caching of a plug-in like Ubershape. For what? Such cache of animation can occupy many gigabytes of disc space and even its reading will be slower than simply to force the plug-in to repeat its analytical model’s building.

Any non-linear transformations (deforms, morphs, plug-ins) are recalculated from scratch if any of their source data is changed (or they have time-sensitive flags). AFAIK that’s same in all apps.

Motion blur requires to know vertex’s position at previous frame, but this position is never read from HD. Each “transformer” is responsible for correct motion data creating (often it needs to repeat all calculations with “minus time delta”)

Hmmm… agree/disagree doesn’t make things faster :slight_smile:


#63

Igors,

What you have in mind to make plug-ins faster to calculate?

Tomas


#64

Hi, Tomas

What we said in #1 of this thread: link a slow (or problematic) plug-in to a “saver” that provides a file cache