PDA

View Full Version : UVs and Nodes



Amurrell
09-11-2014, 10:14 PM
Is it the nature of the beast to not be able to show UVs in a node network in openGL? If so, how do you guys and gals deal with this frustration of not being able to visualize them?

Of course I have been taking the object to layout and running VPR, to see them, have placed them in the color channel without nodes activated, which helps but was wondering if there was something that I was missing. If not, I'll keep working around it.

Sensei
09-12-2014, 06:04 PM
The main problem is LightWave flexibility. We can have "infinite" quantity of UV maps per object or surface.
And we can change UV per spot, dynamically.
OpenGL needs definite UV map. And middle UV values will be interpolated.

Why do you want to see UV in nodes?

Isn't enough to switch viewport mode to display UV map?

jasonwestmas
09-12-2014, 07:45 PM
you'll have to visualize UV map coordinates in modeler's viewport.

Amurrell
09-13-2014, 12:59 AM
I have multiple elements that need to line up correctly, so I like to check it on the models. Some of the elements are subpatched and need subpatch interpolation where others are not and do not. The only way I can see how they line up is on the model which makes adjustments easy. Now if I don't use a nodal network to apply the materials and UVs and use the layer system, then the texture can be seen, but the layer system doesn't afford me the flexibility of the node system, but when applied through nodes, OpenGL doesn't see them (the UVs) and I have to render it out in layout.

It's pretty much moot at this point, since I have had to go to another package to finish the project since LW is bogging down quite a bit.

jwiede
09-13-2014, 02:15 AM
The main problem is LightWave flexibility. We can have "infinite" quantity of UV maps per object or surface.
And we can change UV per spot, dynamically.
OpenGL needs definite UV map. And middle UV values will be interpolated.

LW knows how many maps are "attached" and should be able to recognize the (extremely common) singly-UV-mapped usage case and offer proper OGL representation for that. I doubt most would be upset if cases of more complex multi-map projections used the "first referenced", or even better, allowed user to designate which UV map should be used for OGL representation of the nodal surface.

jasonwestmas
09-13-2014, 09:07 AM
I have multiple elements that need to line up correctly, so I like to check it on the models. Some of the elements are subpatched and need subpatch interpolation where others are not and do not. The only way I can see how they line up is on the model which makes adjustments easy. Now if I don't use a nodal network to apply the materials and UVs and use the layer system, then the texture can be seen, but the layer system doesn't afford me the flexibility of the node system, but when applied through nodes, OpenGL doesn't see them (the UVs) and I have to render it out in layout.

It's pretty much moot at this point, since I have had to go to another package to finish the project since LW is bogging down quite a bit.

Not sure what you mean by "multiple elements". Sure opengl only views the UV textures that are in the old-style layers system but that doesn't mean you can't setup the nodal textures on top of that. When you press F9 the Nodal system will just override the layer textures without disturbing opengl texture setups.

In what way is lightwave bogging down? Your bounding box threshold should combat slow navigation somewhat. Also try tumbling/navigating inside of VPR which is faster than opengl.

Amurrell
09-13-2014, 09:38 AM
Not sure what you mean by "multiple elements". Sure opengl only views the UV textures that are in the old-style layers system but that doesn't mean you can't setup the nodal textures on top of that. When you press F9 the Nodal system will just override the layer textures without disturbing opengl texture setups.

In what way is lightwave bogging down? Your bounding box threshold should combat slow navigation somewhat. Also try tumbling/navigating inside of VPR which is faster than opengl.

Well you just answered my question about the UVs, but it's lagging in modeler and sucking up memory in layout.

In modeler I have an object of about 450k polys, but I lost quick editing. They are a mix of faces and simple sub patches so no CC subdiv. But the system is crawling, which I have never seen before and am wondering what the heck is going on.

In layout, it reports the object has 1.7 million polys (since it is freezing the mesh) object memory is 437M and render memory for this is 305M (statistics panel in layout reports 33.2M but the render window reports higher) but layout is eating up 3.5G. Once after an F9 the memory footprint dropped to 1.7G, but I have not been able to replicate it. Modeler's foot print was 700M (oddly after the render this dropped to 450M).

Old configs nuked, nothing weird running in either portion of the app. I'm at a loss.

124226

Maybe I should get rid of all the PSDs and use a different format as well.

jasonwestmas
09-13-2014, 10:21 AM
Well first off, Catmull Clark in Lightwave is horribly slow, so just in case you didn't know I would stick to subpatches until you go to render then you can convert your models back to CC. CC also subdivides to many more polygons at the same levels as subpatches. So you will want to keep your subD render levels around 2 (for CC) most likely then increase that if needed. Also I'm not sure if LW3DG fixed the UV problem with CCs, they don't work with discontinuous UV flow.

PSD files are huge so that is part of the problem too. Try png.

Since LW doesn't have bucket rendering it will use a huge amount of ram in general to freeze the meshes and render a frame. (In my case this makes displacements difficult with only 8 GB of Ram, so I rely on normal maps and png format a lot).

Yes modeler performance is the number one complaint I think. Try another modeler perhaps or compare 11.6.3 to older version of LW. I find LW 10.1 a little snappier actually even though I like a lot of the features in 11.x. Modo is cool because you can save out .lwo files (with V-maps) and layout will just update the changes if they are already loaded.

Amurrell
09-13-2014, 10:33 AM
Thanks for the info. Been trying Modo, but it tweaks the UVs ever so slightly when saving out to lwo (maybe something I did). Gives me a message saying that not all surface data can be saved directly to lwo, but it is a lot more snappy editing.

Sensei
09-13-2014, 01:13 PM
LW knows how many maps are "attached" and should be able to recognize the (extremely common) singly-UV-mapped usage case and offer proper OGL representation for that.

No, it doesn't know. It knows only total amount of UV maps in entire scene.
(all nodes contributing to the same example surface):
1st node can use "UV Map 1"
2nd node can use "UV Map 2"
3rd node can take "UV Map 3" and then modify UV values the way it wants (randomize, offset, flip or whatever)...
4th node can take multiple UV maps, in random or selected by user order.
And read pixel completely unpredictable.

LW has no idea about which UV (or UVs if multiple) node is using.


I doubt most would be upset if cases of more complex multi-map projections used the "first referenced", or even better, allowed user to designate which UV map should be used for OGL representation of the nodal surface.

OpenGL must have baked textures.
Each pixel of texture f.e. 1024 * 1024 = 1 mln pixels must be rendered,
see how long it takes Surface Baking Camera to do it's job.
That's what you would have to wait for OpenGL preview..