PDA

View Full Version : animation UV cycler - REDUNDANT AND CLUMSY



jin choung
12-19-2006, 05:47 PM
howdy all,

long time no see! anyhoo, just started getting into version 9 and i've found a clunky interface thing that can be cleaned up:

the animation UV cycler is supposed to allow us to create animated texture effects when using UV MAPPED textures.

this is wrong-headed and clumsy and still does not give us the flexibility of changing SIZE or ROTATION of textures on the uvs etc.

THE IDEAL IMPLEMENTATION would be to simply "OPERATOR OVERLOAD" the current legacy texture placement controls for SCALE, POSITION, ROTATION, FALLOFF.

i know that these control the placement of the texture on the "implicit" uvs on lightwave's legacy projections.

BUT THERE IS NO REASON that these controls can't be made usable for uv map textures. maya does this as does max and basically, it controls the scale, position, rotation, falloff of the TEXTURE PAGE in relation to the stationary uvs.

just make it so that if you are using these controls on a uv mapped texture, the controls simply function differently under the hood.

then, we will get scale and rotation control as well as position and EVERYTHING will be "E"nvelopable.

i consider this a mistaken and clumsy implementation on par with the initial implementation of the uv map ui and the initial implementation of camera mapping ui.

so please fix this and give us the more sensible, robust implementation.

thanks.

jin

Sensei
12-19-2006, 06:22 PM
AnimUV plug-in class was added in LW8.0 and any 3rd party developer can write his/her own plug-in that modifies UV in time, but I know nobody that wrote any AnimUV plug-in..

jin choung
12-19-2006, 06:27 PM
the anim uv cycler is embedded in the texture controls. it is not a third party, it's built into lw.

when you change the texture from a legacy projection to uv mapped, you get a little pull down that lets you activate the cycler.

again, i think this is not good. we should just be able to use the legacy texture controls to control and envelope EVERYTHING... every kind of texture.

jin

Chris S. (Fez)
12-19-2006, 10:56 PM
Jin...the old school is still in session. I thought you were long gone:).

Agreed. Rocket-science UV controls like in MAX are long overdue.

Sensei
12-19-2006, 11:34 PM
Jin, I know exactly what is Anim UV cycler, don't tell me where I should look for it in Texture Editor, lol.. I am just telling you what it is from LW SDK v8.0+ point of view... Anim UV cycler is the only AnimUV plug-in class example written so far that I know, but there is way for any programmer to extend it through AnimUV plug-in class defined in LW SDK http://www.newtek.com/lightwave/developer/LW80/8lwsdk/docs/classes/animuv.html, but nobody did it yet.. Reason? Not very useful IMHO..

Sensei
12-19-2006, 11:42 PM
again, i think this is not good. we should just be able to use the legacy texture controls to control and envelope EVERYTHING... every kind of texture.

That's simply doesn't make sense.. These controls are defining projection from 3d world (xyz) do 2d world (uv), and UV mapped texture was already projected.. Then if you want to UV can go through Anim UV that will modify u, v or both.. And yes, AnimUV cycler was badly programmed old way with Panels instead of XPanels therefore it lacks envelopes for its parameters..

jin choung
12-20-2006, 12:56 AM
hey sensei,

right right, it is working in 3d coordinates now. but my argument is that it should change to 2d coordinates when you select UV MAP as your "projection".

so instead of moving in x,y,z, you move in x,y (u,v) and rotate is in one axis only and scale is in two dimensions as well. AND, all the envelopes that are available for the traditional projections will be available for animating the bitmap in relation to uvs.

my point is that we should "operator overload" the interface that is there instead of doing a "bolt on" interface like the uv cycler.

basically, maya allows you to generate your uvs but then, you can still position or animate the bitmap in relation to your uvs using an interface very similar to the one lightwave has for the traditional projections. we should just do that. much simpler.

jin

p.s. true spline looks frickin' awesome. howabout hookinig up with lwcad's nurbs curves? you guys can provide the SURFACE functionality that lwcad doesn't....

jin choung
12-20-2006, 10:37 PM
hiya chris,

yup, still around and still using lightwave. but have had to devote my attention and energies to other aspects of life of late.... this life thing is very very intrusive! :)

jin

sire
12-22-2006, 06:49 AM
I think the better approach would be to have something like the Morph Mixer, only for UV VMaps instead of Morph VMaps. Then not only the usual transformations would be possible but anything.

jin choung
12-23-2006, 11:52 PM
that's cool.

but i disagree.

it doesn't really make sense to me to actually animate UVs.... at least not a lot of situations where such a thing is necessary.

better to just control the texture page in relation to static uvs. essentially, it might be the same thing in terms of how it is implemented in the programming but to me, it seems to make more sense to just give me (apparent) controls to reposition the texture instead of giving me control of the uvs with a vmap animator.

so depending on the texture controls, the display of the texture in the uv view moves and scales and rotates etc.... while the uvs themselves just stay where they are.

jin

sire
12-24-2006, 02:35 AM
Okay, you have a point. And texture page rotation would be rather difficult to do with just VMap morphs.

SplineGod
12-24-2006, 08:44 AM
I agree Jin. It would be nice to have more then just rudimentary UV animation in LW. Nodal adds a bit more power as well but not to the degree Id like to see.

faulknermano
12-29-2006, 12:20 AM
i dont get it.. couldnt you just plug it in this way: item info.Position > Image.UOffset (color Out) > Color Layer.color > Shader.

Lightwolf
12-29-2006, 03:41 AM
i dont get it.. couldnt you just plug it in this way: item info.Position > Image.UOffset (color Out) > Color Layer.color > Shader.
The problem is... the offset doesn't work when you want to rotate the image.

Ideally (imho), the projection pipeline should be as follows:

|- UV Generator (either using explicit projection modes, or UVs, this is where a UV morph could be implemented)
|
|- possible UV transformations
|
|- actually usage of the UVs for mapping purposes (and not only for images either)

Unfortunately at this point in time all of these are contained within a single node/texture layer.

Cheers,
Mike

faulknermano
12-29-2006, 03:57 AM
The problem is... the offset doesn't work when you want to rotate the image.

how so? isnt there a rotation pluggable attrib in the Image node? i just checked. i can rotate the image and apply U or V offset. strangely, U and V offset is not listed in the Image node interface, but can be plugged. hmmm...

zardoz
12-29-2006, 04:23 AM
so...what people are asking here is like a morph map but for uvs? being able to morph uv maps?

Pavlov
12-29-2006, 04:28 AM
It's another of the thousand things which will be gone when modules will be fully integrated.

Paolo

Lightwolf
12-29-2006, 04:49 AM
how so? isnt there a rotation pluggable attrib in the Image node? i just checked. i can rotate the image and apply U or V offset. strangely, U and V offset is not listed in the Image node interface, but can be plugged. hmmm...
Is that using UV mapping though?
Currently the transformation controls control the projection to UV(texture) coordinates, which in turn are modified by the UV offset, tiling etc.

Cheers,
Mike

jin choung
12-31-2006, 12:03 AM
zardoz and others,

basically, the way i see it is to simply make the size, rotation, position numeric fields OPERABLE when used in context with a uv mapped texture.

as of now, it is made INOPERABLE.

but this does not NECESSARILY have to be the case.

in maya, you can PROJECT your uvs and parameterize your mesh into uv space. THEN, you can adjust how the texture is placed in relation to the static uvs and you can animate those values. this is very much like simply making our texture controls operable when used with uvs.

as i said, just OVERLOAD those preexisting controls so that it works in the context of uvs as opposed to lw's legacy projections.

consistent, clean, predictable and self explanatory. very good things in regards to an interface.

jin

Lightwolf
12-31-2006, 04:14 AM
basically, the way i see it is to simply make the size, rotation, position numeric fields OPERABLE when used in context with a uv mapped texture.

The problem is (consistency again), that currently the transformation settings defne how the projection modes create the (internal) UVs.
So in this context, if they were operable for UV maps they would still have no functionality, since there is no explicit projection that creates UVs, but rather existing UVs are read from the mesh.

We'd basically need a way to post-process existing UVs (including the ones created by the projection modes) - and have those consistent throughout. The node inputs are a start for that kind of functionality.

I have to admit I'd still prefer to have the actual projection split from the handling of the (resulting) UVs, at least as far as the nodes are concerned.

Cheers,
Mike

jin choung
12-31-2006, 04:24 AM
The problem is (consistency again), that currently the transformation settings defne how the projection modes create the (internal) UVs.
So in this context, if they were operable for UV maps they would still have no functionality, since there is no explicit projection that creates UVs, but rather existing UVs are read from the mesh.



howdy mike,

right! exactly!

that's how they operate now on the legacy projections.

but this is why i talk about "OPERATOR OVERLOADING". they would work DIFFERENTLY (internally at least) when used with texture mapping on a mesh with explicit UVs.

differently as in - it controls the TEXTURE MAP (or page)... as it lies in relation to the STATIC UVs that were created in a discrete, previous step.

so when i change the POSITION now, i am not doing anything discernible in the UV VIEW to the uvs themselves. the uvs are STATIC. but if i have the BITMAP visible in the background, THAT has moved. and if i rotate, again, that has moved.

the uvs are static and we are just changing how the texture page is in relation to the static uvs.

THEY WORK DIFFERENTLY (internally, programatically) but they feel like they are doing the same thing in uv mode as they do in legacy mode and we can ANIMATE the position, rotation, etc. again.

and this is pretty much how maya does it and it works great and i really miss it when i go back to lw... especially since i see the controls are RIGHT THERE!

hope that made sense.

jin

Lightwolf
12-31-2006, 04:34 AM
hope that made sense.

Hi Jin,
it does make sense. I don't like the idea however, because it only solves a single problem (at the cost of more confusion).
However, it does not allow the user to modify the UVs created by the projection modes (which can make a lot of sense as well) only the ones read explicitly from a mesh. Basically, it is not a universal solution, that's why I don't like it.

Cheers,
Mike

jin choung
12-31-2006, 05:08 PM
hey mike,

that's cool.

i guess it just makes sense for me cuz of the maya connection (and other apps too come to think of it).

they treat it as 2 discrete steps. 1 - project your mesh (parameterize it) into uvspace. 2 - allow numeric placement/rotation/scale and animation of the image relative to the projection.

you're completely right, it would do absolutely nothing to the uvs. but for me, that makes sense as being in step 1.

but viva la difference! :)

jin

Lightwolf
12-31-2006, 05:16 PM
Hi Jin,

no worries. I see what you mean and what you want. I'd just rather see a full solution than a half baked one that only adresses a part of the issue.

If you look at Maya, what you want for LW would indeed be a part of step 2, since step 1 in the case of mesh UVs would just read out the values.

LW basically has no step 2 at the moment (or a very simple one in the case of image nodes). One of my main gripes with the design of the nodal shading system. It is currently easier to use, but duplicates functionality within ndes that imho should be separate (look at the duplication of projection modes within the 2D procedurals as an example).

Cheers and a Happy New Year from 2007!
Mike

faulknermano
01-01-2007, 10:08 PM
hi mike, sorry, but i cant understand what the issue is that "image-reprojection-to-static-uvs" cant solve. zardoz comments made me think however, and i find being able to morph uv coordinates to another is a good idea. is this what you mean by post-processing uvs? if so, this will entail more than simple transformations, like translate, rotation, or scale. if not, what is the difference between using simple transformations on UVs (per se) as opposed to using simple transformations on projected images?

Lightwolf
01-02-2007, 02:47 AM
hi mike, sorry, but i cant understand what the issue is that "image-reprojection-to-static-uvs" cant solve.

Try this:
Front project an image onto an object... now rotate the image (without changing the projecting camera).

Also, rotating in UV space is like rotating the texture image itself,while the rotations of the projections produce different results.

Cheers,
Mike