UV mapping and subdivision surfaces

Alex, I actually just said I would andquot;lookandquot; at it. Don’t get too excited andnbsp;

Richard

Erk…

Richard, two things:

1. Unwrapping/UV mapping a complex mesh is agonizingly slow. 3DC hangs when I try to zoom in or move around the UV mapping window. Sometimes it’ll let me do it, sometimes not.

Yeah, yeah, I know you’ve said before that 3DC doesn’t like objects with heavy point counts, but still…subdivision surfaces don’t really come into their own until you’re doing complex models.

2. Those little green cubes you use to represent points in the UV mapping window are WAAAAY too large and completely obscure complex meshes when I try to unwrap them. Like, all I see is this giant green mass of closely packed cubes…I can’t see the lines at all. I sort of have to depend on the 3D preview and guesswork when trying to line up multiple surfaces.

I’d love to do it all entirely in 3DC because I’m sick of external apps completely screwing up my hierarchies and pivot points, and there are some things that you just have to completely finish modeling before unwrapping, so doing one little part at a time is not an option. Can you optimize the UV mapping and reduce the size of those point cubes? Or at least have an option where the user can shrink/resize the cubes?

-Mel

To be honest, the UV mapping was never designed to handle the large number of points associated with sub-division surfaces.

Do you have an external unwrapper that handles directx? If so, it should preserve pivot points and hierarchies.

Richard

This is what I was talking about…you can’t unwrap something this complex until after you’ve committed it to its final shape. At this point, 3DC crawls when unwrapping it.

If you try unwrapping it before you commit, it works after a fashion…that is to say, the final UV map will be based on the original low-poly geometry and will be distorted on the smoothed final surfaces. So there’s no avoiding it, you have to commit before you unwrap.

That’s not a problem for me…3DC’s speed when unwrapping it is my problem. To be fair, adding more RAM may solve this problem…but I’d still like to know from Richard if there’s anything bottlenecking the unwrapping code.

-Mel

Fair ‘nuf.

-Mel

I don’t like using external unwrappers because more often than not, it creates an unnecessarily huge amount of work. If I use non-DirectX formats, I can preserve quads and other n-gons…but the meshes get split by material instead of groups. If I use a DirectX file, the external unwrapper triangulates the geometry and ruins the material properties. Either way, stuff happens without my permission.

So I prefer to do everything within 3DC.

-Mel

No…I’m using subdivision surfaces to create high-poly organic models from a low poly starting point. And no, I’m not committing the surfaces before they’re ready.

What I meant by that comment is that subdivision surfaces are a wonderful way to quickly create complex and fluid models.

Hehheh, give me some credit for brains. I’ve been creating 3D models since the early 1990s, and 3DC is simply my latest tool.

-Mel

Hey, Alex! Long time no see. How’ve you been?

Yeah, stability is more of a priority than adding features…I agree with you on that. I’m basically driving Richard crazy with my incessant stress-testing of v6, hehheh…

v6 is a huge leap forward in terms of tools and functionality available to the artist. I’m pestering Richard to enhance the UV-mapping capabilities because 3DC is already capable of so much that it’s astonishing to see it fall short in even one area.

Part of the reason I did the robotic bug is because I guess I wanted to convince Richard that 3DC is capable of professional quality output, since he seemed a little disappointed that the subdivision surfaces and other advanced features weren’t really being used.

I figure if I’m gonna ask him for Enhancements A, B, or C, I should at least show him WHY I think they’re necessary. After all, he’s got a lot on his plate and quite likely has to juggle possibilities from version to version based on what he feels is the correct priority.

I’ve told him that there’s a few things that would really round it out and polish it some more, like fixing a couple operations (Flip, Mirror…minor issues involving correct relocation of mirrored pivot points for complex hierarchies), updating some capabilities to better complement each other (in-place editing for Surface Tool primitives so they can be used with subdivision surfaces, such as using them to accurately create a cloak or even a face for a human character built from extruded/smoothed standard primitives, for instance), and finally, finishing up the UV-mapping capabilities (so models created with all the advanced features can be tweaked and then finished entirely inside 3DC, which will be more than can be said for a lot of other packages that cost a helluva lot more)

Those things, I think, will finalize its current modeling capabilities, based on my conclusions from modeling that bug. After that, truly new features would only be gravy.

-Mel

The bug’s about 10,000 quads or so, including all limbs and subparts.

Regarding what you said about the modeling approaches, it’s all sound. Informative too, which is a big help for the newbies around here.

My ideal vision of how 3DC’s unwrapping would work with SDS models would be allowing me to unwrap the low-poly control geometry normally, and then applying the same smoothing to the UVs that it does to the geometry.

It’d make texturing SDS models much less painful. That is to say, if I started with a cube, the UV map would start out as being something like a box map…but after applying the smoothing, the UV map would be smoothed into the same final shape as the newly subdivided cube, which becomes much closer to a sphere.

3D painting would be very sweet, and could even be coded as a plugin using the Viewport controls if there were some way to retrieve the hDC of the model’s current texture so realtime painting/previewing could happen. Then the model could just be exploded into faces across the texture, and a smart brush would paint only on and across whatever face is currently moused over in the 3D preview window. Of course, one could take the long way around and just update the texture from file as one paints rather than doing memory operations on GDI or DirectDraw surfaces.

One of my old apps, Ray Dream Studio, had a rudimentary 3D painting capability that allowed modelers to create vector-based painting shapes, pixel brushes, etc that wrapped around the model. When used in combination with another old app, Metacreations Painter3D, there was actual realtime painting capability. RDS also was much more suited to heavy geometry, being geared more towards creating higher-definition models for video and rendering.

That’s one feature I’d love to develop for 3DC, but I’d have to do some more research on exactly what I can do with the 3DC scripting API before I take on that task. Like, for starters, I don’t think there’s a way to figure out in the Viewport control what polygon the mouse cursor is over without actually selecting it.

For the current SDS implementation, I’d be perfectly happy if the UVs were updated in place along with the geometry after subdivision occurs. Then I could just unwrap the starting geometry and not worry about distorted UVs post-smoothing.

-Mel

[BLOCKQUOTE class=’ip-ubbcode-quote’][font size=’-1′]quote:[/font][HR]For the current SDS implementation, I’d be perfectly happy if the UVs were updated in place along with the geometry after subdivision occurs. Then I could just unwrap the starting geometry and not worry about distorted UVs post-smoothing.[HR][/BLOCKQUOTE]

I thought it did this.

Richard

Here’s an illustration of what I was talking about

Richard,

Oh, it does. Problem is it stays in the same shape as the control geometry rather than being rounded and softened to match.

If you unwrapped a cube that was autosmoothed to 2 with a tension level of 0…you’d see a quasi-sphere in the 3D window and a really dense square cube in the UV window instead of a quasi-sphere like you’d expect.

So the texture won’t line up accurately on the 3D model unless you unwrap after you commit. But unwrapping after you commit is a pretty bad idea because the UV system, like you said, wasn’t designed with huge pointcounts in mind.

Which is why I was thinking it’d be great if the UVs got smoothed and rounded with the geometry instead of just subdivided within the extents of the control geometry. Then the subdivision primitives would be even more fun to work with.

-Mel

Bumpety-bump, so Richard sees the preceding post…

-Mel

I did read the post. I just didn’t realize I was supposed to respond. IMO the existing UV positions shouldn’t change and if I am understanding your diagram you are suggesting that they should. Am I understanding you?

Richard

Yep.

I’m also a texture artist, and I happen to think it’s critical that the UV map be as distortion-free as possible. If the UVs don’t change upon subdivision, then the map will be distorted, and texturing will be incredibly difficult. In which case, it’s pointless to UV map a model before committing the smoothing to it.

Yet on the other hand, it’s also pointless to UV map a model after committing the smoothing because, like you said, 3DC wasn’t designed to handle that many points. So logically speaking, it would help if the model could be unwrapped before smoothing while the pointcount is still on the sunny side of manageable, ESPECIALLY if the UVs are updated to maintain the same shape after smoothing.

I also don’t think it’s sensible to use an external unwrapper when there’s already a perfectly good UV mapping capability inside of 3DC…the solution is to either update the UV map to match the smoothed geometry while staying inside andquot;bounding boxesandquot; established by the previous UV coordinates, or enhance the existing UV mapping capability to handle higher pointcounts. I’d be satisfied with either approach.
-Mel