Preserve UV

[Williams, Wayne]

If you have a frozen texture projection on a mesh, is there a max like Preserve UV option if you need to move edges just a bit and not have the UV stretch??

 

Wayne Williams
Venerable Geneticist, Human Coercion
Senior Character Artist
wayne.w...@xaviant.com

Xaviant
 
Cell           770.722.0778

http://www.xaviant.com
  Where all will be made clear

 

[Matt Lind]

No.

[Williams, Wayne]

Thanks Matt. I remember having asked a while back but haven’t upgraded to 2012 so was unsure if it had the magic sprinkles or not. Ah well.

[Matt Lind]

Let me elaborate.

 

If the projection is implicit (planar, cylindrical, spherical) You can use the ‘swim’ and ‘stick’ features in the projection menu.

 

If the projection is explicit (arbitrary UVWs), then you are out of luck.

 

Matt

[Guillaume Laforge]

Maybe you could workaround it by cloning your freezed mesh and then from the clone use Gator to get the UVs. Moving the Gator op upon modeling region, you could move your points and the UVs would slide (as with Gator, they would be generated using a closest location on the original freezed mesh).

My 1/2 UVs

G.

[Matt Lind]

This is something that should be part of the tweak tool, worst case.

 

 

Matt

[Guillaume Laforge]

>This is something that should be part of the tweak tool, worst case.

It sounds like you don't like my workaround. If it was in the tweak tool it won't be a workaround.

[Matt Lind]

Exactly.  We need solutions, not workarounds.

 

There’s a big difference between something that is technically possible vs. something that is practical/feasible within a limited timeframe.  The GATOR workaround may technically solve the problem in some cases, but the overhead in setting it up and cleaning up when finished can outweigh the benefit of just dealing with the problem manually.  This is a longstanding and growing problem in Softimage overall.

 

Our props team only gets 2-4 hours to make a prop asset from scratch to completion including review time for approval by the lead/director.  It’s very important artists have ready solutions to their needs. A GATOR workaround would eat up too much time for somebody with such a limited schedule to futz around with and figure out.  In many cases, what they need to do is not even possible because of limited GATOR workflow.  If an artist forgets to cleanup and exports the prop to our game engine, now we’ve got a new problem which consumes more time to track down and deal with.  At which point any gains the workaround would’ve provided have now turned into a deficit and added stress. You may think this is extremist, but this is our everyday reality.

 

Softimage is technically capable of performing many feats, but it needs a lot of streamlining from the user’s point of view to be a viable option in rapid pipelines like ours.  It currently relies too much on technically savvy people being present to assist the general user for things that other resolve without requiring such intervention.  ICE is another example, while very powerful, it lacks the polish at the simpler levels to make it efficient to implement and support at the user level.  Many of the things that need to be done don’t sound technically complicated (or interesting), but they need to be done.  In all the years I’ve been using Softimage, this is the #1 complaint I get from users (besides bugs) – hands down.

[Guillaume Laforge]

For sure, if the user can do it with one click on the good button it will always be better.

(well at least for some users...)

[Matt Lind]

A lot of the barriers we’re running into now aren’t so much a button being missing, but rather tools having tunnel vision.

 

Example:  Merging polygon objects.

 

Currently a merge operation creates a new mesh.  Works just fine, but the act of creating a new geometry forces the user to redo hierarchies to accommodate the change including renaming of objects and deleting the old ones.  Doable, but can be time consuming and lead to human error when pipeline specific details need to be maintained.

 

2^nd problem is merging objects merges the properties based on chronology instead of by name or other more useful attribute.  If two meshes each have multiple vertex color properties (say 3 on each mesh called “one”, “two”, “three”), Softimage won’t match the “one” property from mesh A with the “one” property from mesh B.  Instead it will find the first created vertex color property from mesh A and merge it with the first created vertex color property from mesh B.  Not useful if mesh A’s properties were created in the order: one, two, three, and mesh B’s properties created in the order: three, two, one as the result will be “one/three”, “two/two”, “three/one”.  The biggest problem of all is Softimage has no way of sorting the properties to be paired up manually through the UI.  A user without scripting skills cannot solve this very basic problem.

 

Example 2:   how construction history is interpreted by modeling operators.

 

In 3DSMax there is a tool called “mirror plane” (or something like that).  Very interactive and helpful in creating trees, bushes, and other assymetrical meshes with localized symmetry.  Basically it’s a combination slice and symmetrize tool.  A plane (grid) is manipulated by the user to slice a mesh and symmetrize it across the plane. When the user manipulates points on the original mesh, the equivalent points on the symmetrized half are updated as well.  If topology is changed on the original mesh (add/remove subcomponets, apply material, edit UV, etc…), the symmetrized half sees the changes and responds accordingly.

 

The problem with softimage is it cannot replicate this workflow.  Using the low hanging fruit technique of writing a script to wrap around the ApplyOp() command to apply slice and symmetrize doesn’t work.  It can create a plane and apply slice and symmetrize, but edits that occur later in the construction history are not seen.  They’re ordinary movecomponent operations.  This limits the user to only manipulating the mirror plane to cut the mesh.  I tried building this tool using ICE modeling but ran into the same limitation as the ICEtree cannot be moved above it’s insertion point in the construction history as a dialog pops up stating moving the ICETree will destabilize the system.

[Raffaele Fragapane]

The gator "workaround" is actually relatively easy and painless to automate and garbage collect for a user and implemented into a couple buttons. I have exactly that for my work at home and took half an evening to put together and prettify.
That said, given the tweak tool is already (clearly enough) capable of storing and referencing the pre-tweak state of the mesh efficiently (see slide option) I agree it should simply be an option in there, a fourth one in the UI that will swim properties (all of them!).

The modelling stack/modelling precedence issue I wholeheartedly agree with.
Topology in XSI has been problematic and hard to manage for a long time now. ICE goes an incredibly long way to address some of the issues on the proceduralism side of things when you're ok wtih only creating or not modifying the mesh before your operator, but still falls short of the mark when it's time to wedge that manipulation inbetween existing parts of the history.

A managed addition to the stack entry points that allows for topo ops, something like post-modelling between modelling and shape, and changing the default or tools such as component mirroring and eventual custom tools to end up in there, would be a painless, backward compatible and highly workflow enhanching addition.
The fact that pretty much anything one could write, even if we wanted to in first place, requires a second object, cripples even the places that can put the RnD time into extending the platform.

[Matt Lind]

As I think about it more, the preserve UV option should be build into the texture operator or implementewd as a general operator so it can be activated/deactivated from anywhere and not limited to the tweak tool.

 

Swim needs to be more granular than ‘all or nothing’.  We need UVs to swim, but not vertex colors.  We need normals to swim, but not userdata.   Each clusterproperty on the mesh should have it’s own setting.

 

Matt

 

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane
Sent: Tuesday, June 21, 2011 4:29 PM
To: soft...@listproc.autodesk.com
Subject: Re: Preserve UV

 

The gator "workaround" is actually relatively easy and painless to automate and garbage collect for a user and implemented into a couple buttons. I have exactly that for my work at home and took half an evening to put together and prettify.

[Guillaume Laforge]

I agree with you on a more generic implementation of such feature. And if a true swim "task" was developed, I don't think it should be build on a "point locator workaround". An UV swim function would take the old polynode position and the new one and would update the UV with a "magic formula" (doing the magic in triangle space or something like that). Maybe we could do it in ICE in fact ;).

G.

[Matt Lind]

If ICE, how would you access it from the texture editor?

[Guillaume Laforge]

ICE would do the swim operation. So you could open the texture editor a edit your texture projection.

This is only for "pure" ICE Vector3 attributes that you can't see them in the Texture Editor, not for Texture Projections.

[Matt Lind]

Let me reword the question:

 

How will an ICE operator be able to manage the swim if the user’s edits occur higher up in the modeling construction history?  This is basically the same problem as cited earlier with the mirror plane tool.

[Guillaume Laforge]

you put the ICE op in a higher region of the construction history than the current one.

[Guillaume Laforge]

current one = current mode

[André Adam]

Let me point out that we have tried the GATOR workaround in the past. It does not work. And here is why:

If you have splitted your texture projection into various uv islands, where the geometry points related to the uv boundaries are still connected, GATOR fails at random to catch the right uv coordinate. Which is only natural, given the closest distance algorithm GATOR is based on.

And yes, a true swim functionality for the TE is highly needed. Don't even bother creating ICE stuff for this, our artists won't touch that thing. A hard TE implementation is what they want.

    -André

[Szabolcs Matefy]

For this I used to use GATOR. Duplicate mesh, use GATOR on the original, and project everything back onto your original mesh. Now you can tweak your mesh, and UVs will be projected from the original model. Poor man’s PreserveUV. I made a little Addon containing my tools. It build into the UV editor’s tool menu.

 

 

Cheers

 

 

Szabolcs

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Williams, Wayne
Sent: Tuesday, June 21, 2011 9:24 PM
To: soft...@listproc.autodesk.com
Subject: Preserve UV

 

If you have a frozen texture projection on a mesh, is there a max like Preserve UV option if you need to move edges just a bit and not have the UV stretch??

[Szabolcs Matefy]

I can imagine an operator doing the following:

 

1.       Collect the points from the geometry that are connected to the point in question in the UV space

2.       Check the distance the point moved in relation to the collected points

3.       Reproject distance to the uv space (the distances from the connected points)

 

Or something like this

 

 

 

Szabolcs

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Szabolcs Matefy
Sent: Wednesday, June 22, 2011 8:13 AM
To: soft...@listproc.autodesk.com
Subject: RE: Preserve UV

 

For this I used to use GATOR. Duplicate mesh, use GATOR on the original, and project everything back onto your original mesh. Now you can tweak your mesh, and UVs will be projected from the original model. Poor man’s PreserveUV. I made a little Addon containing my tools. It build into the UV editor’s tool menu.

[Raffaele Fragapane]

It isn't exactly only natural or related to closest distance. It happens because GATOR will work off points even when treating a pointPerPoly property. It happens because there can be no boundary management when that treats all samples on a point as the same. If it matched per sample and matched the direction of the sample (enclosing edges) in those cases, you would find for identical topologies it would be flawless, and would also still work for topologies that aren't too mis-aligned as well.

Multiple islands decoupled into multiple projections will work just fine, with a final projection being just the sum of those kept in sync with an op.

Again though, with all that said, it remains an involved workaround, and I agree the functionality should be built into the toolset, especially given that those are some areas where XSI's API isn't exactly well furnished nor intuitive/convenient.

--
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

[André Adam]

This is what I mean, I moved the select point just the tiniest bit to the left (exactly along minus x worl axis), and the whole thing blows up into pieces (see attached pic). A proper TE swim needs to be based on uv island data to properly work.

    -André

[André Adam]

I tried to give the simplified explanation... ;)

[Raffaele Fragapane]

Fair enough. I gave the overly complicated one to say "try to split them into multiple projections and see if it works for you" :)
Splitting the projection into islands procedurally is trickier than it should be, as the API offers very little to look up points and edges from samples or any other matching convenience functions in point locators, but it's trivial to bruteforce if you don't mind a few seconds of machine grind per projection.
It does remain a workaround rather than a solution, but it beats nothing :)

[Piotrek Marczak]

SI 2014 – skip all ice updates and make tons of small features that will make 99% of freelancers and generalists happy!

 

btw do you have video of good swim function in any 3d soft? 3ds max fails with something more complex than box (exaggerating)

From: André Adam

Sent: Wednesday, June 22, 2011 8:31 AM

To: soft...@listproc.autodesk.com

Subject: Re: Preserve UV

[Eugen Sares]

About the Operator Stack:
I very much agree with Raffaele and Matt!

The beauty of 3ds max' Modifier Stack is it's ability to work with any
Modifier anywhere in the Stack anytime, Topo or Deformer or whatever, and
see the end result of the complete Stack simultaneously.
Simply select a Modifier in the stack and the next Modifier you apply gets
placed above it.
There's this Pipe-Icon, called "Show end result on/off toggle".
If you want to speed things up, you can disable evaluation, but if you
need interactive preview, like with a symmetry setup, it's there.

It's possible in Softimage to work beneath Deformers with full stack
evaluation, but not for Topo Ops like Symmetry.

I note max' Modifier Stack and SI's Operator Stack are fairly different,
but from an artist's point of view max wins.

Some Operator stack oddities:

- Activate Modelling Construction Mode, create some Mesh, tweak with Move
Component Tool, so you get a MoveComponent Op (or a folder).
Move the Op up in the stack, and back down. Sometimes I get the evaluation
error. Difficult to tell when.
Sometimes I can drag the Modelling marker beneath the Op (instead of
dragging the Op above the Marker) without the error, sometimes not.
Sometimes I can drag the Op to Animate or Secondary, and back down,
sometimes it gives the error. Putting it first under Shape Modelling and
then down under Modelling helps in this case.

Other Deform Operators like Bend, never seem to show the error.

Really hard to see a pattern in this... but believe me, the error shows up
when you play around long enough.
Seems to make a difference which Construction Mode was active in the first
place, also.

- Above Modelling Construction Mode is Shape Modelling Mode - why can Topo
Ops not reside here, since it's declared as a Modelling Mode?
If this was possible, you could put the Symmetry Op under "Shape Modelling
Mode", switch to "Modelling Construction Mode" and tweak while seeing the
symmetric end result simultaneously.
Actually, the blue Marker should be named "Shape Deform".

- It is possible to disable the stack anywhere in the Topo section, apply
a Topo Op, and enable what's above again.
If this is possible, why does evaluation above have to be turned off at
all??

I'd like to suggest an idea, similar to Raffaele's:
best would be to have a new Marker, maybe black, that can be placed/moved
freely in the stack, indicating where the next Op goes, Topo or not, with
full evaluation!!

When that Marker was somewhere in the e.g. Animation section, a new Deform
Op would be placed there.
A new Topo Op would be placed under Modelling automatically (like it is
now when in Animation mode and a Topo Op is created).

When the Marker is somewhere in the Modelling section, setups like for
Symmetry would be possible!!

This could accompany/complement the Operator placement via choosing the
Construction Mode.
Shift this hypothetical Marker to Animation, and see Animation
Construction Mode getting selected automatically.
Know what I mean?

I suppose the restriction that Topo Ops must reside at the bottom of the
stack is not changeable without ripping the heart and guts out of
Softimage, but at least there should be more flexibility with Topo Ops and
stack evaluation!

And, please fix the issue that Custom Topo Ops (oldschool ones) have
problems selecting new Components created inside the Op!

ICE Modelling is great and powerful, but it shouldn't be used as a
(complicated) workaround for weaknesses in the basic Operator architecture!

Thanks for reading,
Eugen

[Szabolcs Matefy]

Don't get a flame war here, but modifier stack sucks. XSI history is
fairly better, but more streamlined management would be useful. We have
the disable from here, and freeze to the give operator, and in many
cases XSI reacts better to topological changes than Max. But the subject
is the preserve UV, that is a MUST. No workaround, but a solution. If
it's ICE, fine with me. In the animation or shapemodeling history, since
they are not affecting the topology, but should be built up on the
modeling...

Cheers

Szabolcs

-----Original Message-----
From: softimag...@listproc.autodesk.com
[mailto:softimag...@listproc.autodesk.com] On Behalf Of Eugen
Sares
Sent: Wednesday, June 22, 2011 12:11 PM
To: soft...@listproc.autodesk.com
Subject: Re: Preserve UV

[Guillaume Laforge]

> Let me point out that we have tried the GATOR workaround in the past. It does not work. 

I know that André, that is why I said latter on those posts that we should use a specific method in triangle space to do the swim.

Gator workaround was just a workaround but it can help sometime btw.

> And yes, a true swim functionality for the TE is highly needed. Don't even bother creating ICE stuff for this, our artists won't touch that thing. A hard TE 

> implementation is what they want

It is not a question of ICE or not ICE. What you are asking for is a command that an artist can run from a menu in the TE. This command will apply an operator in the stack to control the UV swim. This operator could be an ICETree with a swim UVs compound or a dedicated swim operator.

ICE is not less used by "artists". In fact they don't care if it is an ICETree op or not ;). 

G.

[André Adam]

Guillaume,

you will have to admit that the combination of "here is a workaround" and "you can go and knock up something to that in ICE" sounds a lot like a dead end to any feature request. Therefore I felt it was needed to point out that we do not have a workaround and that we very much would favour an out-of-the-box solution provided by Softimage dev. :)

Cheers!

    -André

[Eugen Sares]

On Wed, 22 Jun 2011 12:18:14 +0200, Szabolcs Matefy <szab...@crytek.com>
wrote:

> Don't get a flame war here, but modifier stack sucks.

Didn't deny this... ;}
I just said in terms of flexibility, it wins.
Anyway... only thing interesting here is what helps Softimage become
better.

My point was suggesting another free Marker for more granular placement of
Operators in the stack, so new Ops can be placed beneath other Topo Ops
like Symmetry, and see the result of the whole stack simultaneously.
That's a must in my opinion as well.

> XSI history is
> fairly better, but more streamlined management would be useful. We have
> the disable from here, and freeze to the give operator, and in many
> cases XSI reacts better to topological changes than Max. But the subject
> is the preserve UV, that is a MUST. No workaround, but a solution.

++1

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

[Guillaume Laforge]

I realize every day more and more that I can not express my ideas on this list as easily as before :).

When I was a "cg artist" trying to help other ones on this list before, if my solution was not the good one, it was not a problem, it was just a suggestion.

Now that I'm a "software developer", giving the same kind of advice will sound to you as "a dead end to  any feature request".

I'm not speaking as the official Autodesk Softimage leader on this list, so don't worry about any "dead end" after my replies ;).

Now I'm wondering again if I should be part of the usual brainstorming when we are trying to help each others on this list ?

Cheers,

G.

[Jens Lindgren]

I'd really hate to see you stop giving us awesome tips & tricks and I think it's up to all of us non-AD people to accept that most of the things you write here is from your artistic and private point of view.

Shame on us!

 

/Jens

--

 

 

Jens Lindgren

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

Lead Technical Director

Magoo 3D Studios

[André Adam]

Now, nothing wrong with any suggestion made from anyone in this thread. You proposed possible solutions and others, including me, proposed different ones. That shouldn't be a problem, is it?
On the same lines, Softimage devs in charge of things are listening to feature discussions on this list. Therefore, if one has a different idea about a future development, it is reasonable to add it to the mix. None of my mails would have been any different if you were not with Autodesk. And I strongly hope they were not offending in any way, because that's not what they were meant to be!

Cheers!

    -André

[Robert Chapman]

Exactly! Leave Guillaume's helpful ideas alone, it would be a real loss if he was ostracized from offering workaround suggestions due to 'Developer' status politics. Please don't stray away from Brainstorming Guillaume, its incredibly useful with the ICE trees you do post :)

[Guillaume Laforge]

Thanks guys :) (Jens, Andre and Robert).

Now every time I will need some love, I will just need to say that I will stop to follow the list ;).

Cheers

Guillaume

[Sandy Sutherland]

Guillaume,

Please do continue - there are many of use who DO value your input
greatly!!!!

Regards

Sandy

[Stefan Kubicek]

+1 for more flexibility in the OP stack, I too find it irritating that some operators cannot be moved around in the stack freely, or only under certain conditions
that are hard to foresee or understand. I'm not entirely sure whether I'd need yet another relocatable "black" marker in the stack to mark the entry point for new ops,
but the ability to put any op anywhere in the stack anytime is very much needed (e.g. Symmetrize Polygon Op cannot be put above the modeling section of the op stack), especially in the modeling stack.
I can imagine that this would require some substantial changes of parts of the architecture (an undeducated guess though, I'd love hear the opposite), and ICE doesn't seem to change that picture as Topology changing
ICE Trees do not evaluate above the Modeling stack either (I just tried with a Merge Polygon Meshes node), but I'd love to hear about ideas or plans in that direction, if any.

--
-------------------------------------------
Stefan Kubicek Co-founder
-------------------------------------------
keyvis digital imagery
Wehrgasse 9 - Grï¿œner Hof
1050 Vienna Austria
Phone: +43/699/12614231
--- www.keyvis.at ste...@keyvis.at ---
-- This email and its attachments are
--confidential and for the recipient only--