Baking Plug-ins?


#41

There is no lighting technique without problems. Here is a very simple experiment:

  • create an XZ plane
  • place a radial light above it
  • animate the light (move it up along Y-axis)

Result: more distant light produces MORE illumination (not less as in real life). Of course, it’s just an example but please note: even “elementary” thing has problems (btw: “elementary” does not mean “simple”). If we consider, say, bitmap shadows, we can find a tenth of problems, not say about RT shadows and GI. Each method has its advantages and disadvantages, it’s a normal “dialectic” in CG world. But, Jens, we listen you and we hear “advantages only” :slight_smile: (of baking approach). Looks like only narrowed/limited developers don’t understand great advantages of this technique :wink: LOL

Sorry, but in our experience CG is not a place with “milky rivers and kissel beaches” (don’t know how it’s in English). Let us to remind you the back side of this great approach

  • several hours of pre-calculating is absolute NOT slow/bad for scene you showed. From engeneering point of view. But please tell us how to work with this practically. Our first acquaintance with EI radiosity: calculating… Two hours later: an indicator definitily has moved? Or nope? Next morning: still calculating… Ok, “direct way” is not a way to go, clear, simplifying settings, ok, here are rough but enough fast results. Ok, “interpolating” render time, balance speed/quality etc. Yes, all is possible (and even not very complex), but… please agree: any talk about “easy to use” is out of the question.

  • a class “fly only” of animated scenes (nothing is moved/changed except camera) is not a little, but please tell us: what to do with others? A partial solution (even perfect) still remains a partial (for camera fly only). Yes, it’s not a little, but… it’s a part only

  • (maybe most important). Any changing of scene forces re-baking. But what’s a difference? I need too re-render too with GI etc, right? Yes, right, but with baking you could see nothing before baking is finished. And it’s a big difference in practical work

Please think about these little things listed above before you, gentlemen, apploud to illum baking and talk condescending about modest Monte-Carlo GI :slight_smile:


#42

Hi, Hans

Hans, there is a good medicine for “love from first view” - it’s just a second and further views. Please test and use it more - then we would be happy to hear about your results/experience


#43

Please do not get me wrong. I never said that baking is the solution to all GI render problems, but it certainly has advatages over plain GI render and is more efficient for certain tasks. Does it provide a solution for changing light situations? No. Does it provide a solution for the interaction between moving objects and baked objects? No. Does it need rebaking if you want to change the scene? Yes. As you said, its all true.

It is just a very useful tool/technique - at least for me. Also Monte Carlo GI is a useful and most aprechiated tool and technique for me, but not the most efficient in all cases. I do not argue against you, I argue from my experience as a CG artist - its just my opinion. But if I listen to you I could get the idea that you diminish the advantages and that you might think it is an overrated feature. I think its not. Its just a normal controversal discussion.

I applaud it for the benefits. I do not use it when there is no benefit. Its one technique of many with its pros and cons - just like MC GI. Baking is not needed in EI - but if you look at it this way, what kind of new feature is needed at all in the EIAS?


I think we should pick up at the point where Uwe suggested to utilize the radiosity engine for baking, since that was an attempt that catched your attention. So, how could this be done and what are your thoughts in this regard?

Jens


#44

i am sure you understand that illum baking is already in use by the people here and others, with all the pros and cons you mentioned. and i guess they are all aware of this.
if you use it just for fly-bys or use it for the enviroment and comp your main subject in later (with dynamic lighting/shading), it is still a very usefull technique.
it is NOT limited to camera fly-throughs.

for a project i did in 3ds max some time ago i used baking (not only illum but shaders also) for the whole enviroment (a highway with vegetation around) with a truck crashing on it.
the action was rendered seperat in brazil, the rest with max scanline. after first tests we calculated around 2 weeks pure rendertime on 5 maschines -> past deadline
with baking and multi layer rendering this project was rendered in around 3 days pure rendertime. sorry, i can’t give you exact numbers, because this was freelance work for an other company and i don’t have the project anymore.

so, let me repeat: it is already in use, just not in EIAS.


#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