"Encage" Plugin: Viable Render-Time SDS?

#5

Hello, gentlemen

>>…because the subdivided skin that Encage produces won’t update with the bone-deformations.<<

Any model plug-in receives “not bone-deformed yet” input (geometry of its child groups). Thus simply apply skinning to plug-in (Encage) group, not to children.

>> When skins are moved with bones, they wont motion-blur.<<

Fixed in June 2005 (as we remember, Manu asked about it)

About Catmull-Clark and Loop.

Yes, Loop sds scheme works with triangles only. Catmull-Clark can be applied to anything but works much better for quads and n-sided polys. Both schemes are standard, but each program implements them in different ways, for example, a simple plane is sds-ed differently in Maya and 3dsmax. But absolute all implementations are very sensitive to source cage quality. “SDS is not a tool to correct bad meshes” as the old wisdom modeler said.

>> I’d definitely be willing to pay some decent money ($US300-ish) for solid implementation of subdivisions within Animator <<

Encage’s implementation is absolute not solid :slight_smile:

#6

Oooh, I didn’t realise that. Thanks for the tip.

You’re right, I just didn’t realise that that version was the one on general release. So again, my apologies for the misinformation.

Anyway, sorry to put you off Giacomo. Encage is definitely a good thing. You’ll get very clean meshes when doing serious deformations that a standard mesh wouldn’t stand up to.

#7

In fact, dear Igors, now that I have your attention. I tried a little XP script to switch the Encage Animator (editing) resolution from 0 to 1 interactively. It works fine when I switch from 0 to 1, but when I switch from 1 to 0, the model disappears. I have to switch Encage off and on again to make the model reappear.

#8

No sorry please :slight_smile:

Encage is not “good” or “bad” - it’s just one of SDS implementations. For some cages it works better than others SDS, sometimes results are same, sometimes, yes, worse. It’s normal, “ideal SDS” is not discovered yet.

Looks like you don’t know what to do :slight_smile: The standard way is: simplify your prj up to minimum and send it to us

#9

Hang on. I suddenly remembered why I always attach the actual geometry to the bones rather then the Encage plug-in. If you attach the Encage group, you’ll end up deforming the high-res skin. Deforming the low-res model results in a really smooth mesh once Encage does its thing. And that’s what I mean when I say that Encage is good thing, after all, that was the point of Giacomo’s original posting.
So yes, Encage will help you get rid of those joints breaking, but only if you attach the low-res cage to the bones. And that will only work if you keep the model at level 0.

Actually, all you have to do is take any project that has Encage in it. Switch “Subdivision Steps Animator” to level 1 or higher. Go into Encage again and set it to 0, click ok and see what happens. Every time I do this, the model disappears.
None of the other settings in Encage make a difference.
If you can’t reproduce it from my instructions, let me know.

#10

This has happened to me several times. So I can verify that.
I’ll add (while im here) that Encage is fantastic and has been worth every penny!
Ian

#11

Steps:

  1. Create a simple cylinder and skin it with 3 bones
  2. Add MrBlobby and set “Facet blobs” in his interface
  3. Link skinned cylinder to MrBlobby. Blobs are ready
  4. Change the bone chain. Blobs are not updated
  5. Switch MrBlobby group visibility OFF/ON, it forces the update

Same for Encage, same for any model plug.
So, summary: we are sorry for host doesn’t do what you need :slight_smile:

Aha, usual story (instructions instead of prj)

Steps:

  1. Create a new project with Ubershape cube
  2. Add Encage and link the cube to it. We see SDS “spheroid”
  3. Open Encage and set “Subdivision Steps Animator” to zero. Click Ok, we see original cube

Hmm… where is a prob? Don’t spend your time for instructions, a test prj is the shortest way, sure

#12

I understand, all technology has its limits. I was only pointing out what the workaround is. Animating at level 0 is not bad, it makes for a very responsive interface.

Done

#13

What machine have you got Ian?

#14

It’s happened on my work machine, a dual 2ghz G5 with 10.4.4

Next time it happens i’ll strip out a project and send it in.
Ian

#15

I already did that and the Igors couldn’t reproduce it on their G4. What graphics card have you got?

#16

I have two (dual monitors), i’ll have to have a look tomorrow because it’s my work computer, ill edit this post to let you know.

Edit: They’re both Radeon cards, a 9200 and a 9600 (both 128meg).

I duplicated this bug in a project today, but when i tried to delete all the other objects EI crashed (huge scene). I’ll try again when i have more time.
Ian

#17

I have to be short right now because I am beta testing somethings but this is a really important topic that I would like to interject a point or two. So pretend I’m talking really loud because I want to get my point across.

First, you should not have so many breaks with a character deform. I have heard rumors that there is a problem with weight map skinning and this sounds like one, though I haven’t experienced it first hand. You shouldn’t have ripping in your deformation on simple geometry. That’ s not how EI is suppose to work. It’s a character tool by itself. You should not have to buy a plug to fix it. It should just work. Yes, buy Encage, but not by force as a bug fix.
I have low poly character meshes that work BEAUTIFULLY NOW. I rigged them almost two years ago. I haven’t created a new skin object. I hope and PRAY this is not a problem, already I heard that people are leaving EI because it’s not working properly. We must fix the root problem and not throw patches and plugs to fix it. Encage stands alone as a beautiful tool but is a extra step to if someone wants a fast and simple workflow.

Second, I have had the same problem with Encage model jumping when I switch back to a low resolution proxy. I love Encage for ZB work. Encage has the potential to be a necessary tool to proxy models for high end film work and high resolution texture. Zbrush must use Encage because even simple color maps must be rendered at the same resolution it was painted at in Zbrush or the UVs with look wobbly. This is a resolution problem not UV, Zb, EI,or Encage problem.

I have a full test character that I skinned which works with Encage if I skin the plug, but the skin jumps off the rig if I switch back to Zero. It’s still there but is in a new position.

#18

If there are true problems, I’m sure they will be fixed. Its too important to the new FBX pipeline for weight maps not to work. Anyone leaving EI may be leaving a bit prematurely on this one.

#19

Sorry, I know this could be really bad PR. It’s all very premature, and I haven’t test the problem for myself. I don’t know for sure if there’s a true weight map problem from my first hand exprience. As stated, it’s just too important to overlook. I guess I’m being slightly paranoid because I don’t want to have such a problem when I start rigging agian. It is simply not possible to rig any character without good wmps and softening fall Off. I have never had a problem with wmps in EIAS before. Maybe the people complaining are at fault. I don’t know for sure.

I also apologize to Igors, they do excellent work. And Yes, EI programming team has been excellent at resolving any reports ASAP. 

I see no reason to abandon EI, it's too USEFUL and powerful and fast.
#20

BTW, I have had no problem with FBX weight maps or skins that were generated in Maya and imported to EIAS. I believe the complaint was with wmps directly generated in EIAS. It wasn’t wide spread just one or two sources that were constant. I know they enjoy being annoying.

#21

Radeon eh? Exactly the same type of card that I have. I wonder what the Igors are running on their machine

#22

I would suggest getting encage. I love the fact that I can work with low poly characters in realtime and render out hires ones without swapping at render time. You do not have to do sample renders, just turn up the tess in animator to see what you will get.

Here is the first test I did with encage. The base polymesh was a little messy and has since been fixed, but this test still shows what great results one can acheive using this plug.

Before Encage:
http://www.morleyarts.com/testinglab/beforeencage.html

After Encage:
http://www.morleyarts.com/testinglab/afterencage.html

Richard

#23

Richard-

Looks great.

About the “Encage bug you ran into with the doubling of model size,” though…is this a frequently occurring bug with Encage? I’m not sure I want to be dealing with something like that on a regular basis.

GM

#24

Thanks
Well, it was partially user error. I did not realize that when using encage you can’t scale an object within animator before linking it to the plug. When you turn the plug on, suddenly the object jumps to that scale. For instance, I think this character was 1.0 in scale, so I increased it to 2.0, then linked it to encage. Once encage was enabled, it jumped 2x in scale in animator. When it rendered out though, it was the correct scale. Easy fix, make sure your model is the correct size, export as parked fact, reimport and link to encage, end of issue. It’s a pain in the butt but easy enough to work around. I wish they’d update it so this wasn’t the case.

Hope this helps.