PDA

View Full Version : Lightwave penguins in Old Dogs teaser



Mr Rid
06-17-2009, 08:14 PM
Lightwave was used for several shots of CG penguins in the upcoming movie, Old Dogs (November release). A couple of brief shots are in the low quality teaser.

http://www.traileraddict.com/trailer/old-dogs/trailer
YT-
http://www.youtube.com/watch?v=wiB1cz6y-8o

Poor quality image, but in the zoom-in shot where they open their beaks and screech, the foreground penguins are LW with Sas fur. And the penguin tugging on Travolta's ear. Some interactive splashes were also done with PFX and HV (cant see well in ear tug shot).
74454
74455

GraphXs
06-17-2009, 09:49 PM
Nice work, care to talk more about the workflow and rendering?:hey::thumbsup:

Matt
06-18-2009, 03:15 AM
Great! Love the bit where they all turn around!

Looks like a funny film!

Cageman
06-18-2009, 03:45 AM
Well done, Mr Rid! I assume you are still at Pixel Magic?

Looking forward to see this movie. Looks like fun!

:)

IMI
06-18-2009, 04:52 AM
Looks pretty good. :thumbsup:
I've been wondering when Robin Williams was going to do something again.
Ultimate frisbee... gotta see that. :D

EDIT;
oops, the whole point - the penguins look awesome.

mav3rick
06-18-2009, 09:59 AM
AMAZING... well executed .... nice to see good old sasq perform well nowadays :)

wildr3d
06-18-2009, 01:25 PM
Looking good there Mr.Rid! What was the schedule like?

JeffrySG
06-18-2009, 01:55 PM
Sweet! :D

Mr Rid
06-19-2009, 12:46 AM
Nice work, care to talk more about the workflow and rendering?:hey::thumbsup:

I wish I could post better quality examples but have to wait until the movie is released in November.

The penguin was actually left over from Good Luck Chuck. I believe the model was originally purchased somewhere. Only the crash zoom shot used fur since it was so closeup. The rest of the shots were wide enough that the bare mesh looked fine.

Four people had a hand in the fur/feathers which became the biggest technical nightmare I have ever had to deal with because of the way the rig was set up initially. I know most people dont understand at all, but I want to slap anyone who automatically assumes every model should be subD, and layered. I have run into so many problems with this. But the biggest problem was that the model was rigged and furred as a 14 foot penguin, then later parented to a null which scaled it down to actual scale. Folks, this is a BIG no-no, but is a lot to go into. I came into the project late and had no choice but to deal with the setup.

But a top notch animator named Sean Scott animated the penguin shots. He always nailed accurate weight, speed and performance in one pass. I did lighting and some splashes and wakes.

For the fur shot, the original background plate was a zoom in. Instead of tracking it, I sticky front projection mapped the first frame onto a rough version of the ice ground and back wall. This allowed for a more dynamic dolly push-in (which the client preferred) instead of the flat zoom and we could also then easily change the speed of the camera move. The front projection mapped set would also cast appropriate radiosity lighting on the penguins, but...

Sas fur only renders with spot lights that dont have realistic shadows, and took way too long to render at 2k, even with self-shadows only, then forget about radiosity. So I used the surface baking camera to render the penguins without fur, with a more realistic area light and radiosity. The resulting UV was applied in the fur color channel so radiosity and realistic shadows are already baked into the fur. A frame rendered with self shadows and spot lights was around 3 & 1/2 hrs per frame, but the baked fur was around 40 mins and with much more realistic lighting, full shadows and radiosity. See, you can get something for nothing. ;D

Mr Rid
06-19-2009, 12:55 AM
Well done, Mr Rid! I assume you are still at Pixel Magic?

Looking forward to see this movie. Looks like fun!

:)

I actually had to leave work due to health problems.

Wild Hogs was panned terribly but did well at the boxoffice, so I expect this to be about the same (same director, producer).

Cageman
06-19-2009, 03:20 AM
Four people had a hand in the fur/feathers which became the biggest technical nightmare I have ever had to deal with because of the way the rig was set up initially. I know most people dont understand at all, but I want to slap anyone who automatically assumes every model should be subD, and layered. I have run into so many problems with this. But the biggest problem was that the model was rigged and furred as a 14 foot penguin, then later parented to a null which scaled it down to actual scale. Folks, this is a BIG no-no, but is a lot to go into. I came into the project late and had no choice but to deal with the setup.

Ouch!

Well... I have successfully done the null-scale thing without ending up with problems, so it would be interresting to hear more about why that is a big no-no. I assume that you mean this is a big no-no in special situations, rather than "never do it" kind of thing? But alas, keeping things to scale from Day 1 will always be the best approach! :)

Also, regarding your comments about subds, I've seen the opposite of what you describe... :) as in... if we were using subds with a renderer that handles them well, we could take advantage of that using displacements. Since Maya/MR handles displacements pretty bad, we end up using corrective blendshapes, which in turn ends up being quite heavy becase of all the detail, and not something you would want to do on EVERY character in a scene (maybe only the one that is really closeup). So, my frustration is somewhat reversed... :)

With that said, I'm not trying to say that you are wrong in any way... I'm just adding my observations and experiences to this, since it seems to be something that has to planned ahead to see the benefits/pitfalls. :)

Anyhow, when you end up in a situation like you describe, especially the problems with subds, you could go for baking out an LWO-sequence based on the display subpatch level and then convert the LWO-sequence into a vertex cache. The first time I used it was with the CodFish (http://www.newtek.com/forums/showthread.php?t=88877) that had to be transfered over to Maya for rendering, and it worked so well so this is now a toolset that I have ready when needed.

In this post (http://www.newtek.com/forums/showpost.php?p=764642&postcount=25) there are links to the two tools I use when I need to create such vertex caches, if you or anyone else would be interrested in testing those.



But a top notch animator named Sean Scott animated the penguin shots. He always nailed accurate weight, speed and performance in one pass. I did lighting and some splashes and wakes.

From what I could tell from the lowres trailer (is there a 720p avaliable somewhere?), the animation and lighting looks really good. To the point that, if I didn't know it was 3D, I might as well have thought they were real penguins, except that having real penguins attacking an actor would probably cost alot of money. :) There are very few giveaways, and for someone not in this bizz, they will probably not spot it. Again, from the trailer, it looks like you guys have improved them even more from Good Luck Chuck (and they look REALLY good in that movie).




For the fur shot, the original background plate was a zoom in. Instead of tracking it, I sticky front projection mapped the first frame onto a rough version of the ice ground and back wall. This allowed for a more dynamic dolly push-in (which the client preferred) instead of the flat zoom and we could also then easily change the speed of the camera move. The front projection mapped set would also cast appropriate radiosity lighting on the penguins, but...

Nice... it looks good and adds a pretty neat effect. :thumbsup: Projection mapping is one of those neat oldschool tricks that never gets old. One of the guys here use that technique alot to speed things up. :)



Sas fur only renders with spot lights that dont have realistic shadows, and took way too long to render at 2k, even with self-shadows only, then forget about radiosity. So I used the surface baking camera to render the penguins without fur, with a more realistic area light and radiosity. The resulting UV was applied in the fur color channel so radiosity and realistic shadows are already baked into the fur. A frame rendered with self shadows and spot lights was around 3 & 1/2 hrs per frame, but the baked fur was around 40 mins and with much more realistic lighting, full shadows and radiosity. See, you can get something for nothing. ;D

That is indeed a VERY nice trick! And yes, it looks good and renders relatively fast. Thanks alot for sharing it! :thumbsup:

On the note of Sasquatch... isn't it time for Worley to make an extensive update to it? :)

Cageman
06-19-2009, 03:21 AM
I actually had to leave work due to health problems.

Oh... nothing severe I hope?

Mr Rid
06-19-2009, 07:07 PM
...
Anyhow, when you end up in a situation like you describe, especially the problems with subds, you could go for baking out an LWO-sequence based on the display subpatch level and then convert the LWO-sequence into a vertex cache.

I have run into so many problems with using subD or layered meshes, or incorrect scale when you then try to add dynamics, plugins, complex rig controls, expressions, or have to merge elements created at opposing scales. I have never needed subD, or layers and again this is exactly what I keep bringing up in various threads about not over-complicating. Stick to the most straightforward approach.

The 'scaling no-no' is exactly what prevents vertice baking from working.

The rig was very convoluted and only 2 pengs could be loaded at once and even then the scenes were taking over 3gb of ram. The animator wound up making his own, much more simplified rig with a single layer Penguin. But I could not do that with the fur scene, and the penguins had to be broken into 5 scenes, because...

Sas was initially applied and tweaked on the 14 foot high penguin model and continues to see that scale no matter how you scale the model in Layout- the settings scale along with the model just as they should. I tried to bake the mesh and discard the convoluted rig in order to greatly optimize the scene(s). But then the 14-foot penguin fur settings do not apply correctly at all to the 18-inch baked mesh- its like applying polar bear fur to a hamster. And Sas values do not scale linearly so it would have taken too much time to redo (involving weight maps), especially since I was new to Sas.

I dont know why it happens but layers often become broken in LW and 'replace object' suddenly stops working- only one layer will replace, or the layers get jumbled- I've seen this happen on every project with a complex character in layers. So you might try to replace each damn layer every time the model is updated, or resort to filepath trickery. I just kept saving over the same version and copying the previous version into an 'old' folder which is not ideal when multiple people are using the model.

SubD was causing a rendering error with Sas where the color UV was flickering oddly on random frames. When I tried to freeze the model it screwed up the look of the fur. These are typical subD problems I run into regularly.

I was ready to stab somebody as I dont know how many weeks went into trying to get a one second shot to render thru the revisions! Considerable time, money, & stress would have been spared if unnecessary subD, layers, and the wrong scale were not used. These problems crop up when doing complicated scenes in Lightwave (with all its quirks) that perhaps several artists are contributing to, and is why I cant stress enough to stick to the most straightforward approach.

jasonwestmas
06-19-2009, 08:36 PM
LW works best with 1 or 2 people per scene, heh :P I also know that in any 3d package, the more people that touch a file with a different computer the more chances there are to corrupt files.

DrStrik9
06-19-2009, 09:32 PM
Great looking work.

I know how totally screwed up it can get when you don't control all aspects of production. You should write a book called, "3D Production Nightmares." -- I'd buy it! :-)

Cageman
06-19-2009, 10:55 PM
The 'scaling no-no' is exactly what prevents vertice baking from working.

That is why I use the tools I linked to in the earlier post in such situations. Have you tried them?

On the contrary, when I did the codfish, I didn't want to spend days on weightmap painting, even less so, I didn't want to have a slow mesh to work with. Regarding deformations, subds are great since they allow you to deform the object, then subdivide, which yelds so much better deformation with little or no effort going into weightpainting. Add displacements ontop of it, and you are now working in a much more efficient way compared to working with freezed meshes.

That is for rigging/animation/displacements....

Rendering, as you say, is a different matter, and I can understand why subds are a bad thing in such situations when using Fur, hence the tools I use allows for taking advantage of both worlds.

The basic principles of the workflow I propose are these:

1. subds used for rig/anim/displacements
2. use IL Save Transformed Sequence to generate an LWO-sequence that has the mesh freezed at the same level as display subpatch level. This will respect all the settings you have applied to the subd object, such as subdivision order and displacement map order. It also respects scale.
3. Use MDD-compiler (external app) to generate a vertex cache based on the exported LWO-sequence (blindingly fast).
4. Create a bindpose version of the freezed object (save transformed object) with correct scale. This object becomes the main object that is used for lighting, shading, fur, rendering etc..
5. Use the generated vertex cache with the freezed bindpose object.

If the character is based on several objects or layers, step 2-5 has to be repeated for each object or layer. IL Save Transformed Sequence only supports a single object, so step 2 have to be repeated 5 times manualy, which is kind of bad from a workflow standpoint (I'll poke some scripters to see of they could create an updated version of this idea that supports multi selections). But, generaly speaking, the plus is that the time it takes to rig and get good deformations on freezed meshes are much, much longer than it is to export these 5 items combined with the rig/setuptime with a subd object.

Once this pipeline is worked through once, the only thing that has to be done in order to update, is for the animator to rework the animation and redo step 2 and 3 to either replace the existing vertex cache or create a new itteration that you can load onto your light/shade/render version.

These types of things needs planning though, and by the sound of it, not alot of planning was done in regards to what techniques to use and how to devise a pipeline where the animator and you could have the best working conditions where it allows you to take advantage of the features instead of fighting them.

You see... I have had so many great experiences with subds, so that is why I argument about them. Hopefully you now know that there are tools around that allows for your workflow as well as a rigger/animator workflow to coexist within the same project.

:)

Oh.... and yes.. about layers... except for prototyping or using control layers (in such cases where Node Item Motion and/or DPKit is used for rigging/controlling purposes), I tend to stay away from them as much as I can, but that doesn't mean they aren't usefull and should never be used. They are nice in Modeler but not fully working as expected in Layout in certain situations.

Cageman
06-19-2009, 11:04 PM
Great looking work.

I know how totally screwed up it can get when you don't control all aspects of production. You should write a book called, "3D Production Nightmares." -- I'd buy it! :-)

It's about communication and planning... and it is important that people who understands most aspects of the 3D-application in use are present at such meetings. I spend tons of time at looking into all kinds of wierd solutions to problems. My use of LW in a Maya-dominant pipeline forces me to be very creative, and as a positive side-effect, I've managed to find a whole slew of tools that works magic, and allows me to be efficient as well as using the workflow I see fit the problem at hand.

It has certanly helped me to not paint myself into any corner, but instead float freely above the floor, picking the best bits and just use them. ;)

Greenlaw
06-20-2009, 02:02 PM
Well... I have successfully done the null-scale thing without ending up with problems, so it would be interresting to hear more about why that is a big no-no. I assume that you mean this is a big no-no in special situations, rather than "never do it" kind of thing? But alas, keeping things to scale from Day 1 will always be the best approach! :)

NEVER, NEVER, NEVER!!! Certainly if you're working here in the Box anyway.

Scaling up or down rigs/geometry causes all sorts of problems with dynamics and sometimes with fur/hair systems. Also, when you scale rigs down or up significantly, the IK can start to behave weird, and the rig can become difficult to edit properly without running into unhappy surprises.

Even if it's a rigid, non-animated object, improperly scaled objects may create confusion to other artists who may use it as a reference to model other objects, only to later learn that their scale is now completely out of whack.

Trust me, scaling objects in Layout might work for your particular shot or when you're the only artist on a production, but on a larger production where elements are shared by many artists and scenes, it can really p*ss everybody else off who has been working at real-world scale, especially when they expected to be able to just drop in an element and move on.

There is simply no reason not start your work at proper scale to begin with, other than being lazy or thoughtless.

Now, having said all that, there are exceptions. For example, you may be working on shots that represent a microscopic world, and the values may become to small to work with in LightWave. In situations like this, it certainly makes more sense to work at a larger scale, but for sanity's sake, everybody on the production must understand what the project's scale factor is from the beginning and agree to stick with it.

Where improper scale can also lead to embarrassing situations when creating pre-vis for live action. Imagine a director or DP saying, "this looks great! So where do we put the camera?," and you check the coordinates in LightWave and discover that improper scaling has placed the camera 10 miles above the soundstage. Oops.

If I sound a bit cranky about this, it's because I've wasted too many hours (on a couple of occasions, days,) fixing problems caused by improperly scaled scenes, objects, and rigs, and with our typically tight deadlines, we just don't have time for this.

Consistent, real-world scale only please. Always. The world will be a happier place for it. :)

Greenlaw

Mr Rid
06-20-2009, 04:22 PM
Wow, you tell 'em Dennis!:2guns:


NEVER, NEVER, NEVER!!! Certainly if you're working here in the Box anyway.

...or anywhere I have any input. And artists will also not be using subD or layered meshes in layout unless "necessary"- key word. But incorrect scale is probably my biggest peeve. I recall Ken Wilder had a horror story about that on Guardian where ocean scenes had been setup with a 1 meter ocean mesh that had been scaled up in the scenes. People will just model something, then throw it in Layout and build a scene around it without thinking down the line.


...
The basic principles of the workflow I propose are these:

1. subds used for rig/anim/displacements
2. use IL Save Transformed Sequence to generate an LWO-sequence that has the mesh freezed at the same level as display subpatch level. This will respect all the settings you have applied to the subd object, such as subdivision order and displacement map order. It also respects scale.
3. Use MDD-compiler (external app) to generate a vertex cache based on the exported LWO-sequence (blindingly fast).
4. Create a bindpose version of the freezed object (save transformed object) with correct scale. This object becomes the main object that is used for lighting, shading, fur, rendering etc..
5. Use the generated vertex cache with the freezed bindpose object.

If the character is based on several objects or layers, step 2-5 has to be repeated for each object or layer. ...

I dont know why go thru all these steps with several layers, scenes and revisions, when you could simply not use subD meshes in Layout. :)

I usually freeze out a high, med and low version of the mesh. Use the low for animation, the med for most pre-final renders, then the high res for final. This eliminates all potential problems with subD that I have seen too much of.

BTW, the random render error I experienced with the penguin's color UV map flickering had nothing to do with Sas itself, and was using 9.3. The error occurred with only the base, undeformed subD mesh and only the color map applied to the surface in an otherwise default scene. I tried different image formats and resolutions and carefully went over the mesh which was perfectly 'legal' in construction. When I froze the mesh the problem went away. That was the only tech problem I ever could not pin down exactly as it occurred at random during the scene load about one out of seven times. Reload the scene and the problem vanished. Somehow LW seemed to be scrambling the UV on the subD mesh during the load.

Every step added to a process only ads potential for problems. I encounter unforeseeable variables on every project and you never know how picky a client may be (may change things several times after 'approval'). Things that seem difficult often turn out easier than expected, and then when I think, 'That'll be a cinch, I've done stuff like that plenty of times' it turns out to be a hair-tearing mess. :bangwall: I look for the path of least resistance.

Cageman
06-21-2009, 03:13 AM
Wow, you tell 'em Dennis!:2guns:



...or anywhere I have any input. And artists will also not be using subD or layered meshes in layout unless "necessary"- key word. But incorrect scale is probably my biggest peeve. I recall Ken Wilder had a horror story about that on Guardian where ocean scenes had been setup with a 1 meter ocean mesh that had been scaled up in the scenes. People will just model something, then throw it in Layout and build a scene around it without thinking down the line.

Yes... don't get me wrong... I do know how important scale is. Trust me, if you are using Maya in production, this is even more important. :)

I never model at work, since my title is 3D Animator, and that there are many needs in the animation department regarding everything from rigging/skinning/animation and fx-work. So, I'm busy as a bee as it is. If something is in the wrong scale that I have to work with, I go back to the modeler and make him/her do the appropriate changes before I continue.

I would have to say that in Maya, it is possibly even more dangerous to use groups to scale items, especially when rigs are involved, because in Maya, you have history and that can truly turn into a nightmare if handled wrong.

:)



I dont know why go thru all these steps with several layers, scenes and revisions, when you could simply not use subD meshes in Layout. :)


I have yet to get as good results as fast with freezed meshes. Freezed meshes doesn't deform as well as subd meshes. Period. And, as I said, this is a pipeline thing, so once you have set it up, you only change in a single scenefile. The rest is handled by the lighting/shading/rendering artist who simply just change the mdds to the new ones (or you simply just overwrite the existing MDDs and the other guy never has to think about it). No more need to use Load Items From Scene in order to update the animation (which also adds to the "feel safer" feeling).

VERY simple and safe... :)



I usually freeze out a high, med and low version of the mesh. Use the low for animation, the med for most pre-final renders, then the high res for final. This eliminates all potential problems with subD that I have seen too much of.

So does my pipeline, except the fact that I can take advantage of the good that subds provide. ;)



BTW, the random render error I experienced with the penguin's color UV map flickering had nothing to do with Sas itself, and was using 9.3. The error occurred with only the base, undeformed subD mesh and only the color map applied to the surface in an otherwise default scene. I tried different image formats and resolutions and carefully went over the mesh which was perfectly 'legal' in construction. When I froze the mesh the problem went away. That was the only tech problem I ever could not pin down exactly as it occurred at random during the scene load about one out of seven times. Reload the scene and the problem vanished. Somehow LW seemed to be scrambling the UV on the subD mesh during the load.

Hence the reason I tend to use subds for rig/anim/displacements and if they make strange stuff when I render, I simply just run it through the pipeline to fix it. So far though, I have yet to encounter the problems you describe with subds.



Every step added to a process only ads potential for problems. I encounter unforeseeable variables on every project and you never know how picky a client may be (may change things several times after 'approval'). Things that seem difficult often turn out easier than expected, and then when I think, 'That'll be a cinch, I've done stuff like that plenty of times' it turns out to be a hair-tearing mess. :bangwall: I look for the path of least resistance.

Every step added to a process without thinking it through, ads potential problems. If you just try things randomly to fix an issue, for sure that is going to hurt in the end. That is what RnD is for...testing all these weird things before actually using them in production.

The codfish was a great RnD-project for me, since it allowed me to try all these things that, at first glance may look cumbersome and timeconsuming, but ended up very beneficial for many, many reasons. :)

So far, I can assure you that the example-pipeline above, works really well when you have to move things around in different apps (not just staying in LW). Most times, the stuff I do in LW ends up in Maya for rendering, and I have yet to run into problems... and most importantly, I have yet to hear anyone get pissed about my delivery into Maya.

Bottomline here is that, in my experience, those extra steps I take, allows me to take advantage of the features in LW in a good way, and I don't have to think about wether the subds will cause problems or not, because if they do, I solve it without loosing the good stuff subds adds, if the subds works without having to do anything, well... more power to me.

:)

Mr Rid
06-21-2009, 04:05 AM
I have yet to get as good results as fast with freezed meshes. Freezed meshes doesn't deform as well as subd meshes. Period.

I have no idea why that would be. Here are two meshes. One is subD, the other is frozen (freezed)...why would one deform any differently from the other when they both render with exactly the same polygons?
74514



Bottomline here is that, in my experience, those extra steps I take, allows me to take advantage of the features in LW in a good way, and I don't have to think about wether the subds will cause problems or not, because if they do, I solve it without loosing the good stuff subds adds, if the subds works without having to do anything, well... more power to me.
:)

But there should be no difference between subD and frozen mesh deformations. So if you freeze meshes you will never have to go thru extra steps to circumvent problems with plugins and dynamics not working with subD.

Cageman
06-21-2009, 07:22 AM
But there should be no difference between subD and frozen mesh deformations. So if you freeze meshes you will never have to go thru extra steps to circumvent problems with plugins and dynamics not working with subD.

Using bones/joints with subds are only beneficial if you set the subdivision order to Ater Bones. What happens is that the result is much more optimized for the pose. Subds are applied after the deformation takes place (as in a bone bending), creating a much smoother result.

Attached are two screenshots. Make sure to take a good look at the area I have marked with a red circle. The first one, is a freezed mesh at level6, the second one is a subd object at level3. As you see, the subd is MUCH smoother even though it uses half the number of polygons.

Both objects are using the same weightmaps, so, in order for the freezed mesh to behave properly, I would have two options... either I take the painfull route into vertex paint or I try to add more bones to smooth out the deformation. Either way will end up making things more of an effort. So, a third option is avaliable nowdays... Baking out an object sequence based on the subd level! In this case, such an operation is only a couple of mouseclicks away, and while the baking is going on, I have three cores left to go on and do other things related to the production.

Cageman
06-21-2009, 07:43 AM
And here comes the other benefit...

When using SubDs, I can apply weights and deformations on the base mesh without having to worry about redoing any weights or tweak deformations when I go higher on the display or render subpatch levels. The weights will always work very smoothly. When freezing an object, the smooth interpolation doesn't come across, except if freezed in Layout using "Save Transformed Object".

Two more attachments. I prefer working with the subd object (first image) since it is very lightweight, is very snappy to work with in modeler and weights are easy to apply. I never had to paint any weight on that one, only selecting points and create weights with falloff. Actually, the weightingprocess for this object was just a couple of hours.

The second image, freezed at level 6, is almost impossible to work with in modeler, and, as you saw, creates uggly results in the deformation department. Replacing my subd-object with this one would cause alot of headache reagarding deformations for me, because, somehow, I would have to edit the weights or add more bones or do whatever I need to fix the deformations.

:)

jasonwestmas
06-21-2009, 08:06 AM
Yeah the main reason I would use SubD is just for performance purposes. It's a lot easier to tweak the mesh details too of course (esp. displacements). Never really had any problem with the old LW subpatch when rendering or animating other than the seams issue you get with discontinuous polys, but that's usually a minor offense. Of course I rarely have to hand off my work to another person so I always know what's going on with the file.

Cageman
06-21-2009, 09:08 AM
Yeah the main reason I would use SubD is just for performance purposes. It's a lot easier to tweak the mesh details too of course (esp. displacements). Never really had any problem with the old LW subpatch when rendering or animating other than the seams issue you get with discontinuous polys, but that's usually a minor offense. Of course I rarely have to hand off my work to another person so I always know what's going on with the file.

Well... I trust Mr.Rid when he says he have had problems using SubDs throughout a pipeline. That is why I argue about the pipeline that actually allows for the use of SubDs where they clearly are beneficial and at the same time removed where they have a tendency to cause problems, such as when rendering. Best of both worlds, I would say....

:)

jasonwestmas
06-21-2009, 11:26 AM
Well... I trust Mr.Rid when he says he have had problems using SubDs throughout a pipeline. That is why I argue about the pipeline that actually allows for the use of SubDs where they clearly are beneficial and at the same time removed where they have a tendency to cause problems, such as when rendering. Best of both worlds, I would say....

:)

True, even though I have used Subpatches in many different situations I certainly haven't used them in all situations.

Greenlaw
06-21-2009, 11:58 AM
Hi,

One potential gotcha we used to run into with sub-d's is increased render times. This happens when your preview level differs from your render level, and Layout/Screamernet pauses to convert the geometry for every frame. Depending on the number of objects, the level of sub-d, and the complexity of the geometry/rig, this can increase render time significantly. We found that you can fix this simply by setting your preview level to the same value as your render level before you send it to render (or instead, as Mr. Rid suggests, freeze your objects.) Mike Popovich created several in-house tools for us that more or less automates optimization tricks like this for us before we commit to rendering; this saves us a lot of time and headaches and, in my opinion, this kind of automation really should be built in. However, matching the sub-d levels of you objects, even if your scene has many, many sub-d objects, is easy to do using the spreadsheet.

Personally, I like using sub-d for 'organic' objects, especially characters, but I strongly agree that it should not be used frivolously. Some artists I've worked with use sub-ds for everything, which simply isn't necessary most of the time, and yes, we found that they can increase the chances for render errors and other problems. Sub-d's certainly have their uses, but if you can get the same render results using simpler, more efficient techniques, all the better.

Just passing on some (hopefully) useful info. :)

Greenlaw

Mr Rid
06-21-2009, 01:48 PM
What Greenlaw said. Yeah, the increase in F9 render times when using varied display and render patch levels was the first thing that threw me off using subD (was worse in earlier versions). Since then I've seen too many gotchas pop up down the line with it. If you setup your rig on a frozen mesh in the first place you should not have deformation problems.

geo_n
06-21-2009, 08:00 PM
Doesn't bother me using subd in stills.
But in animation subd have freeze process and it takes time. I notice that since I used lw 8. But how do you get smooth deform without using subd? Making weightmaps for frozen object would make my eyes teary. :D

jasonwestmas
06-21-2009, 09:11 PM
But how do you get smooth deform without using subd? Making weightmaps for frozen object would make my eyes teary. :D If you first make your weight maps on your low rez cage used for subpatching you can then freeze your object and maintain the same weight mapping. This is "iffy" however and you may have to use the airbrush tool or something to tweak the weights on the frozen mesh. Usually the bones field weighting used in tandem with the weight maps is enough to get the proper deformation. It's not a perfect work flow but it works.

jayroth
06-22-2009, 04:07 PM
BTW, the random render error I experienced with the penguin's color UV map flickering had nothing to do with Sas itself, and was using 9.3. The error occurred with only the base, undeformed subD mesh and only the color map applied to the surface in an otherwise default scene. I tried different image formats and resolutions and carefully went over the mesh which was perfectly 'legal' in construction. When I froze the mesh the problem went away. That was the only tech problem I ever could not pin down exactly as it occurred at random during the scene load about one out of seven times. Reload the scene and the problem vanished. Somehow LW seemed to be scrambling the UV on the subD mesh during the load.


Has a bug report with content been filed for this? If not, can someone do so? I would like to kill it...

Mr Rid
06-22-2009, 07:32 PM
Has a bug report with content been filed for this? If not, can someone do so? I would like to kill it...

I dont know if this bug is pursueable. I dont currently have clearance or access to the assets involved. It occurred quite randomly in LW 9.3 x32 and x64, running in Vista under Boot Camp on MacPros. At the time, I ran the problem by Tim Albee, who also asked Worley and they had never seen it before. Worley suggested a possible RAM issue, but there was plenty of RAM. But white/blank (the global color) splotches would appear in the surface color of our penguin in the exact same places every time the render error occurred. At first, I was sending 4 instances of the scene over to render at a time, on Butterfly set to a single frame range per CPU. Occasionally all 55 frames would render correctly, but more often the random splotches would appear on different frames rendered on different CPUs. I would then cobble good frames together.

Maybe it had nothing to do with MacPros, but at that time we had a problem peculiar only to the Macs (there were PCs also on the network) whenever a TGA was present in a LW scene load- Vista would get an odd dll error. But if you clicked 'OK' the scene would continue to load and work fine (a pain with a network render). We just avoided TGAs.

Cageman
06-23-2009, 12:55 AM
But white/blank (the global color) splotches would appear in the surface color of our penguin in the exact same places every time the render error occurred.

Hmm... it does indeed sound very weird... I have seen issues with subds, but in those cases, it was because of sloppy subd-modeling where "diamonds" clearly was the cause of the problem. But that would never cause the issue you describe though.

Anyhow... now that I know what to look for, I'll keep my eyes open. If I ever stumble across it, I'll fog it!

:)

Mr Rid
06-23-2009, 03:16 PM
We run into so many little non-repeating bugs. Just on the penguin scenes 'load from scene' would occasionally cause a hierarchy to jumble (some null or something would suddenly be parented to the wrong thing), or light exclusions would sometimes change, or on rare occasions one item would suddenly become mysteriously unselectable (I've seen this since 7.5). If you tried to L-click select, or use the scene editor to select a certain item it would instead select a different item. You could select the item in the object list, but then the item refused to move, rotate or scale. But reload and repeat your steps and the problem would not happen again.

One little repeatable bug was each time I would 'replace layer' on the penguin tongue (updated several times) the associated bone would lose it's weight map reference. But no other layer had that problem (I saw a much worse problem with this on a character with hundreds of weighted bones in 8.3). That's another thing I avoid as much as possible are weight maps, and I know a number of advanced character riggers who avoid them for the same reasons. I wish texture maps could replace the function of weights.

I know someone will say how wonderful they think weights are, but after years in production I know what I am talking about. There are just a lot of little odd glitches (not necessarily outright bugs) that pop up when you work in complicated scenes. Some people just love plugins and throw them in their scenes at every opportunity, or modelers assume every thing they model has to have subD, layers and weights, or some insist on always saving out every channel possible. But every tool or process you add to the mix increases potential for problems down the line as the scene or pipeline evolves. If there is an 'old school' way to accomplish the task without weights, layers, subD, plugins, expressions, relativity, or whatever then I avoid complicating the process until it is necessary.

Speaking of penguin tongues, they're creepy-
74584
74585