Freeze modeling and keep the texture support?

[David Saber]

Hello all,

 

I'm modelling a city and I want the map of the city to stay projected on the polygon mesh while I model.

As you know, as long as you keep the texture support connected to a mesh, the texture will slide on the object. This is exactly what I want.

 

But sometimes I need to freeze the modelling. Is it possible to keep the connection with the texture support after freezing the modelling?

 

Also, as I move points and edges (for example with the tweak tool), the texture is following the components, even if the texture support stays connected to the polymesh. Is this normal?

 

Thanks for the help,

David

[peter boeykens]

if you make the projection implicit it will be kept when you freeze the object.

 

I think there is a swim texture option hidden somewhere, in order for the texture not to stick to the geometry, when tweaking components.

[peter boeykens]

there you go: render > modify > projection > swim, stick and reproject.

and search in the docs on swim

 

its all to do with where in the operator stack the texture op sits.

[David Saber]

Thanks Peter! I didn't know such a tool existed.

David

[David Saber]

This function solves my problem N°2 (moving components) but does not solve the problem N°1:

Freezing the modelling, followed by a render > modify > projection > swim, stick or reproject, will make the texture follow the moved components.

I also tried the "implicit" option.

DS

[Alan Fregtman]

Maybe you can duplicate it (so you have a copy of the support),
freeze modeling,
and reconnect it? Property->Texture Projection->Connect to Support

[Grahame Fuller]

Instead of FreezeM, select the topmost operator in the Modeling region and Freeze. It's weird but FreezeM seems to be freezing the TextureOp even if it's above the Modeling region. I'm not sure whether that's a bug or by design.

gray

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of David Saber
Sent: Thursday, March 19, 2009 13:55
To: soft...@listproc.autodesk.com
Subject: Re: Freeze modeling and keep the texture support?

[peter boeykens]

You are right, that seems to be it.
even when you add an operator on a higher level, say animation, and D&D the
TextureOp on there, to force it to read from animation, the TextureOp is
still gone when you FreezeM. I'd say that's highly unwanted.

[Grahame Fuller]

Yep, developer says it's a bug. I just finished logging it.

gray

[Chris Marshall]

Don't forget you can right click on the top most modeling operator in the explorer and do a 'freeze', which freezes all operators below, not effecting the texture supports.

Chris

[David Saber]

Hello guys
Alan, thanks, I was using this trick you told us about: duplicate the
support then Property->Texture Projection->Connect to Support. However,
doing this repeatedly was a bit annoying.
Grahame, thanks for this trick. I already tried to freeze the stack by
selecting it. But my mistake is that I was multi-selecting all the modeling
ops before hitting the "freeze modeling" button. . By right clicking on the
top op and freezing, I get exactly what i want.
Now we have to decide if pressing the "freeze modeling" button has to freeze
the texture support's connection as well. I'd say "no", as in Peter's bug
report.
David

[Chris Marshall]

That's it! I would have thought the reason for having the FreezeM button is to simplify that process, so you really wouldn't want it to knacker your texture ops. This was discussed ages ago and someone from Soft came up with a really good reason why the texture supports are frozen as well, but it makes far more sense to leave them untouched. They were basically saying it wasn't a bug, but an actual feature.

[Eric Thivierge / XSI Database]

Should this be a preference in the user prefs?

--------------------------------------------
Eric Thivierge
Technical Director
Speakeasy FX

[Grahame Fuller]

I'm not sure that a preference is necessary. By default textures stick and so will be frozen with FreezeM. If you've set textures to swim then you've done so deliberately because that's what you want. If you want them to swim for a while but then freeze the final result, it's easy enough to make the texture stick again before freezing.

I thought it was a bug too so I'm interested in anything anybody can remember about that earlier discussion.

BTW to clarify, FreezeM does not depend on which operators you have selected but Freeze (no "M", right above FreezeM) does. The Freeze button is the same command as on the right-click menu.

gray

-----Original Message-----
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Eric Thivierge / XSI Database
Sent: Friday, March 20, 2009 11:27
To: soft...@listproc.autodesk.com
Subject: Re: Freeze modeling and keep the texture support?

[peter boeykens]

make take is this:
If you put the texture op to read from somewhere above modelling, it should
not be frozen when you hit FreezeM

The current behaviour is not consistent with what FreezeM is supposed to
do - that is: freeze the modelling part of the stack and leave all else
untouched.

If you will, the texture op sits outside of the stack in the explorer so it
could even be left out when freezing alltogether.
If you want to freeze it, you can allways just select it and freeze it.

----- Original Message -----
From: "Grahame Fuller" <Grahame...@autodesk.com>

[Grahame Fuller]

My understanding is that the TextureOp is always somewhere in the stack, but you just don't see where it reads and writes from in the explorer. Making the texture swim is equivalent to moving the TextureOp to the very top above Secondary Shape, and making the texture stick is equivalent to moving the op to the bottom of Modeling (just above any generator op if there is one).

Freezing the TextureOp itself will always freeze whatever is below it, that is, the generator if it's still exists and anything else that happens to be there.

I agree that it makes sense for FreezeM to be exactly like freezing the topmost operator in the Modeling region.

[Robert Moodie]

If your texture op is not frozen, in the Explorer expand the
Clusters>Texture_Coordinates_Auto>Texture_Projection_Def
Mouse over the TextureOp and the tooltip will tell you where it's
reading from.

-----Original Message-----
From: Grahame Fuller [mailto:Grahame...@autodesk.com]
Sent: Friday, March 20, 2009 2:28 PM
To: soft...@listproc.autodesk.com
Subject: RE: Freeze modeling and keep the texture support?

My understanding is that the TextureOp is always somewhere in the stack,
but you just don't see where it reads and writes from in the explorer.
Making the texture swim is equivalent to moving the TextureOp to the
very top above Secondary Shape, and making the texture stick is
equivalent to moving the op to the bottom of Modeling (just above any
generator op if there is one).

Freezing the TextureOp itself will always freeze whatever is below it,
that is, the generator if it's still exists and anything else that
happens to be there.

I agree that it makes sense for FreezeM to be exactly like freezing the
topmost operator in the Modeling region.

[Stephen Davidson]

Hello All,

Does anyone know of any documentation (for the average artist) that can
give me a decent grasp on Groups, Layers, Partitions, and how they all
interact with passes? I have read the help docs, over and over, and feel
that I'm missing a piece of the big puzzle.

Best Regards,

Steve Davidson

(954)552-7956
www.3danimationmagic.com

[peter boeykens]

anything in particular you're after?

I dont think a very generalised explanation is going to be very
enlightening.

to an extent, they are "general purpose" organisational tools, and what they
do depends on what you make them do - or in other words: different workflows
make a different use of them. One could show you his way of using them, but
that wouldnt be a complete overview of what they are and do.
This is a bit vague isnt it?

----- Original Message -----
From: "Stephen Davidson" <magi...@bellsouth.net>
To: <soft...@listproc.autodesk.com>

[Stephen Davidson]

Well... yes... but I am getting that impression that
there is no "workflow" that is standard.

I would be interested in rendering different objects in different passes.
What would be the best way to pull that off?
When I create a new pass, the same object, lights, and cameras
are shared in the separate passes. How could each pass
have unique models, lights and/or cameras yet retain some common elements?

Groups? Layers? Partitions? Am I asking a clear question?

Best Regards,

Steve Davidson

(954)552-7956
www.3danimationmagic.com

-----Original Message-----
From: softimag...@listproc.autodesk.com
[mailto:softimag...@listproc.autodesk.com] On Behalf Of peter boeykens

[Guillaume Laferriere]

I would say Partitions.
In your new pass, make the Background Objects and Background Light Partitions not visible to render.
Then,
- Select the objects you want to render in this pass, and create a partition with them.
- Select the lights you want to use the pass, and create a light partition with them.

Guillaume

-----Original Message-----
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Stephen Davidson
Sent: March-20-09 4:45 PM
To: soft...@listproc.autodesk.com

[Stephen Davidson]

Thanks.

[David Barosin]

For rendering I'd just use partitions and in some cases render channels.

The docs are pretty good in explaining partitions and render channels.   

The background partition is a catch all for any objects in a scene that haven't been assign to a partition.

A typical workflow

Create a new pass.
In each pass hide the background partition (hide for rendering/visibility)
Then create new partitions and add the objects to it that you want to render to that specific pass.
You can add materials and overrides to the partition if you want


You can also control light visibility per pass as well as rendering settings. 

[Alan Fregtman]

You can think of it this way:
- Partitions and groups are almost the same. Groups are stored under
your SceneRoot or a Model Null, whereas Partitions are stored per
renderpass.
- Also, Partitions and Layers enforce uniqueness (so you can't have a
same object in two partitions/layers.) Groups allow it.
- Both groups and partitions allow setting properties on them, like a
Display property or "overrides". (Partitions take priority over groups
in this respect.)
- Layers only travel with the scene, whereas groups can travel with a model.
- "Background_Objects_Partition", if you don't rename it,
automatically contains any new objects you make in the scene, in each
pass.
- Partitions only take geometry and lights. Any other object simply
does not show up in them.
- A partition can either have lights or objects in it. Not both types in one.

The "chain of priority" goes like: Layers > Partitions > Groups, where
the first is the highest priority and the last is the lowest. In other
words, if a layer says that some objects won't render, they WON'T,
regardless of what the groups or partitions say.

Does that make things any clearer?

On Fri, Mar 20, 2009 at 4:45 PM, Stephen Davidson
<magi...@bellsouth.net> wrote:

[Shaun Chapman]

Here's all you need to know to get a grasp of these things in Softimage:

Groups: Think of as a list only (not as an object - as in Maya). 
Some Uses of Groups: Set Geom_Approx and other Properties to many objects in the 'List'.

Models: (Model Nulls): These are more like Groups (if you're used to Maya).  Basically, treat these as Scenes within Scenes.  For me I never animate these nulls.  I just use them to 'group' sets of objects.

Passes: Use Partitions to override (Property/Override) Materials and Properties. Use the general settings of 'show' and 'hide' to manage your partitions.

Workflow Tip: When setting up passes, set your default "Background Objects Partition" and "Background Lights Partition" partition to "Hide Visibility" and "Hide Rendering".  This way, when you add new objects to your scene, you're not corrupting your passes with unwanted geometry.

Layers: This is a preference thing, but I rarely use Layers, since all of my Hides/Shows are set by Partitions in Passes.

Hope this helps...

--- Shaun

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

--
PURE - SHAUN CHAPMAN - VFX ARTIST/ANIMATOR
99 Madison Avenue, 4th Floor
New York, New  York 10016
P 212-213-2200
F 212-213-2309

[Matt Lind]

Some simple definitions:

Group - a generic container for associating scene elements for a common
purpose. There is no hierarchical precedence for groups compared to
other groups. The behavior most often observed is that scene elements
will take on the properties of the group it was most recently assigned
(if it belongs to any). scene elements can be assigned to more than one
group simultaneously.

Layer - an organizational tool primarily for working in the viewports
and should not be confused with passes/partitions workflow. Layers have
precedence over groups and are most often used for assigning visibility
properties and wireframe colors. One example of using a layer involves
organizing a character into skeleton, geometry, controller layers for
easier manipulation. Layers are mutually exclusive - scene elements can
only exist in one layer at any given moment.

Pass - an instance of the scene organized for rendering purposes. Every
render pass contains every renderable element in the scene. Each render
pass is a clean slate and not tied to any other render pass. You can
have as many render passes as you like. Each render pass generally
generates one set of images related by a common purpose. Examples:
ambient occlusion, motion vector, diffuse, albedo. Each rendered image
is associated with a specific scene camera. In short, each render pass
has it's own render settings.

Partition - a mutally exclusive group within a pass. Each pass can have
any number of partitions. A partition is mutually exclusive - meaning,
elements within a render pass can only belong to one partition.
However, that same element may belong to different partitions in other
render passes. Partitions are most commonly used for applying material
overrides, visibility properties, and other wholesale changes to the
scene in the rendering context. At least one object partition and one
light partition must exist in each render pass.

summary:

Passes have precedence over partitions.
Layers have precedence over groups.

Layers and render passes can work together, but are generally targetted
for different purposes.

Matt

> -----Original Message-----
> From: softimag...@listproc.autodesk.com
> [mailto:softimag...@listproc.autodesk.com] On Behalf Of

> Stephen Davidson
> Sent: Friday, March 20, 2009 1:45 PM
> To: soft...@listproc.autodesk.com

[Stephen Davidson]

Much clearer..Thanks.

[peter boeykens]

I think a lot of good info came up already.
Just repeating and elaborating a bit.

Its all about propagation of properties.
Groups, passes both allow for applying properties/overrides to objects in a
non destructive way, but with a very different scope.

The group lives on the scene level. You can put it in a model, but that
doesnt prevent objects outside the model to also belong to the group). If
you want to apply some property to a lot of objects for the whole scene, you
can use a group. Eg. apply a material to a group, and add all objects and
clusters to receive this material to the group. another common one is
geometry approximation. The properties/overrides you apply to the group will
apply to all its members, for the *whole scope of the scene*, and will take
precedence over properties applied to the individual objects.
Groups are also commonly used for selection, eg: all deformers for a
character, to be used for enveloping, can be put in a group, so you can
select all of them at once.

Passes and partitions are a very comparable mechanism, BUT you have several
(unlimited) in the scene that live NEXT to one another.
What you do in one pass doesnt affect the other passes. Typically this is
geared towards the output of images (layers and channels) but its not an
absolute requirement. Sometimes I use passes to have different setups of the
same scene to work on different things: eg: for games: one pass would have
the scene setup for baking Hires to Lowpoly, and another pass would have the
lowpoly objects with the baked textures applied. By switching between passes
you can create the bakes on one hand, and verify them on the other - rather
than doing this in two seperate scenes, or having to switch a lot of things
manually all of the time.
Think of the properties and overrides you apply in a pass as "modifications"
on top of the properties the objects have in the rest of the scene,
specifically for the scope of this pass.
Eg, you're rendering an ambient occlusion (AO) pass - you dont want to lose
the material assigned to the object (say: a metal material) in the rest of
the scene. But just when rendering this AO pass you dont want to use that
metal material, but rather an AO material. So in this pass, you would put
that object into a partition, and modify the partition to render as AO.
There's a few possibilities:
You can apply an AO material to the partition and this material will now be
used for the objects in this partition in this pass.
But you could also apply an override to the surface port, and put an AO
shader in there. That way, only the surface part of the materials will be
replaced with the AO. This is usefull, because all the bumps and
displacements of the original materials are still there!
A third possibility is to construct a switch in your original shaders, that
allows to change between different looks, the standard metal look, the AO
look, a specular only look, you get the idea. Now with an override on the
partition, including just the "switch" parameter, you can set the object to
the AO look for this pass.

Layers are a visibility/selectability switching mechanism only - and take
precedence over the other ones.
Think of a car. You might put the main surfaces into a layer, and all small
details into another layer. That way you can quickly hide the details in
order to clean up your view, speed up your work.
A common approach is to use them while building a scene but then to totally
get rid of them when rendering your scene, and handle all visibility within
the passes/partitions.
So you could say layers are more geared towards the modelling/animation and
less towards rendering.

A word of caution: all these mechanisms can coexist and can be used in a
variety of ways.
You can get very smart and set up your scene to help you to do your tasks.
But then you hand the scene over to someone else, and he can't get anything
done in it, since he doesnt know the way you organised things.
So in a collaborative environment, use of these mechanisms can be subject to
convention.