SL and external modelling apps

Reading up on what people do to create textures for SL builds with baked lightmaps and other 'advanced' effects, I've seen various discussion about importing models from 3D apps like Maya or 3DS (and why that's not possible/practicable), but little discussion of doing the opposite. I've also seen people discuss replicating an SL build in their modeling application of choice.

Does anybody know of any tools to help automate that latter option? More specifically, something to take a description of some geometry in SL and generate a mesh in .obj format or something similar? Emarald and various other third party viewers already give us a way to dump prim geometry to an external file. Is there anything that can read that and do the conversion I'm looking for?

Failing that, does anyone know of any code libraries that understand the SL prim system and can produce the vertex data I'd need to write such a tool?

L.

That's something I've thought a lot about. *watches thread*

This topic comes up from time to time. I know people have experimented with XML plugins in Maya, but I don't know of anyone who has yet followed through all the way to make it work. This continues to surprise me, as it doesn't seem like it would be very tough to implement.



One existing option is to pull the geometry out of video memory with an extraction tool. I won't elaborate on this for obvious reasons (don't want to make IP theft any easier than it already is), and hopefully no one else will either. But I will say the results are never clean. What you get is the actual drawn polygons, not the individual prims. The groupings are never what you'd expect them to be. It goes by whatever the graphics card considers to be the most efficient arrangement for rendering purposes within the given frame, not by any organizational logic that might make sense to a human.

If you want to be able to use such extracted geometry for texture baking, you first have to spend time chopping it up into usable pieces, or else just use it as a template upon which to build completely new geometry in a more sensible way. Either way, it's time consuming. But at the end of the day, you do end up with a copy that is close enough to the original for a good bake.

That's an interesting approach I would never have considered. I imagine that rebuilding the model on top of the 'harvested' geometry would be the easiest way to move forward. Going from prims to polys seems like it would make it much easier to get usable UV maps and such fairly directly, though.

Doing this isn't as straight forward as it might seem. I have working code for Modo which creates correctly placed and oriented cubes for each prim in a build, and obviously using more appropriate mesh primitives according to the SL prim type would take that implementation closer to being a usable solution. But it's when you start thinking about how to translate path cuts, hollows, skews, twists, etc. into the meshes that it gets tricky...

I was hoping someone would have done (at least some of) that work already If not, I'll just have to continue experimenting with my prototype and see how far I can go with it. So far I've had little luck finding information on things like the number of segments/slices SL uses to render each prim at any given scale, so that would be useful information if you know where I can find it.

If you know how to read the various scripting languages that are in use, you might find these helpful:

Adrian Linden's Maya ---> SL: http://www.purplestatic.com/MEL_SL/

Jeffrey Gomez's Prims.Blender: /8/64/110607/1.html

Shack Dougall's Prim Composer for 3DS Max: http://liferain.com/downloads/primcomposer/




If you want to know exactly how many polys are in each prim, the answer is easy to find. Simply go into wireframe mode (ctrl-shift-R), and start counting. Here's what I came up with when I did it:

Prism (default): 4 sides x 1 tri per side = 4 tris

Prism (untapered): 8 sections x 8 tris per section = 64 tris

Cube: 6 sides x 18 tris per side = 108 tris

Cylinder: 24 sections x 8 tris per section = 192 tris

Ring: 24 sections x 9 tris per section = 216 tris

Sphere: 24 sections x 22 tris per section = 528 tris

Tube: 24 sections x 24 tris per section = 576 tris

Torus: 24 sections x 48 tris per section = 1152 tris

Sculpty: 2048 tris

I didn't look into every possible cut, twist, and hollow permutation because that would take forever, but those are the basic counts.




All of the above said, the better answer is none of it matters. You really don't need to have the exact right numbers of polys in order to make a replica of a prim for texturing purposes. Think in terms of faces rather than prims, and you'll have a much easier time. That's how we go about it when applying textures inside SL, and it's certainly the mindset we're in when we're creating textures in 2D in Photoshop. It follows that it should also be the same approach we take when we're creating textures for SL in a 3D modeling app.

Keeping in mind that no multi-sided prim in SL has a single UV map that encompasses the whole object, we have to question whether we should be UV'ing on a per-prim basis or on a per-surface basis with each object in each build. Further, since in SL, every side has its own individual UV space, and it's always perfectly uniform, is there any point even in keeping surfaces grouped together as prims at all? After all, for texturing, what is important are the actual surfaces you're working with, not which collections of them happen to be neighbors on any particular prim in-world.

Here are a few things to consider when thinking about how best to reconstruct an SL build in any 3D modeling program:

First, is replicating exact poly counts a worthwhile endeavor? I would submit that in nearly all cases, it's not. For example, why on earth would I want to build a cube out of nine quads per side like SL does it, when one single quad will work just fine? It's not like my good renderer is going to be using SL's primitive vertex lighting when I bake my textures. The whole point of baking in the first place is to use GOOD lighting, and good lighting works just as well on a one-quad plane as it does on a nine-quad or a nine-million quad plane. All things being equal, I don't want my poly count to be any higher than it needs to be. One quad per side will do me just fine.

Second, does my cube even need to be polygonal in the first place? If it's poly, I need to spend time re-UV'ing it, lest I waste a ton of pixels in my textures, since default mapping for a cube in most programs is going to be a crucifix, not a practical layout for SL. In many cases, I'd much rather just click one button to create a NURBS cube, and call it a day. That way, it'll be set up exactly the way I need it, right from the start, as six individual planes.

And it doesn't stop with cubes. How about spheres? If I create a polygonal sphere, I may need to do a couple things with it before I can start texturing. If its normals aren't already smooth, I'll probably need to fix that, or else I'll end up with a texture that looks faceted instead of round (unless faceted is what I want, which sometimes it is). I'm also probably going to need to do a little repair work on the UV map, since not every modeling program maps a sphere by default the same way SL does it. But if I just make a NURBS sphere, I don't have to worry about any of that. It will already be smooth, and it will already be mapped correctly.

Torus, same deal, already smooth, already mapped correctly. The list goes on and on. In many cases, simple NURBS surfaces make far better analogs for how SL prims behave than polys do, for texturing purposes.

Third, adding twists, cuts, and hollows, doesn't change anything. The mapping stays exactly the same. When you cut a prim, you just add a couple more sides. That's all. Same with a hollow. And when you twist, you're not changing anything at all from a texturing standpoint except for the way in which light is going to fall on the surfaces that are being bent.

When you've created textures for SL in Photoshop, have you ever at any time needed to be aware of how many polygons got added to a twisted torus with each new degree of twist? Absolutely not. So why should you need to be any more aware of that when creating the same kind of texture in 3D instead of 2D? There's no compelling reason I can think of. As long as you've got a close enough approximation of the prim shape that light falls across it in the right way, your bake will look correct. The exact poly count, while arguably nice to have if you're a purist, really doesn't make much difference.

Fourth, are whole prims even needed? Let's say I've got an interior wall in SL that is 40M long. It's probably going to be made out of four cubes. If I'm baking a texture for that wall in my 3D modeling app, do I really need all four distinct objects to be there just to bake the one texture that's going to be spread across all of them? No way. All I need is a simple plane 40 units long. That's it.


Here's my usual technique for recreating most builds. I'll trace the key outlines of each structure with simple curves, and then I'll loft NURBS surfaces in between them. It's super fast, just like making a line drawing, only in 3D. I don't have to waste any time UV'ing, or smoothing normals, or messing with any of the other features of polygonal modeling that can often get in the way in this particular context.

Now, to be as efficient as is humanly possible with pixel counts, it does make sense to use polygonal objects here and there, and to UV them proportionally to their actual scale, with long sides occupying the largest parts of a single canvas, and short sides occupying smaller areas of the same image. Then use the repeat/offset settings inside SL to put the right part of the texture on each side.

This kind of thoughtful UV'ing is a great thing to do when and where you can, to cut down on texture induced lag in-world. However, from a practical standpoint, it's not always possible to have time to put that much thought into every prim on every project. Unless you're a real whiz with AI scripting, you can't automate this. It's a human decision-making process that takes a lot of time.

If you just want to keep things as simple and fast as possible, a few curves and a few lofts go a very, very long way for quickly creating a good model on which to bake textures.

There actually is one tool that will extract prim geometry for builds that you created in SL but its only been built to work with 3dsmax and uses a proxy called maxproxy. You can take a look at it at Liferain.com. In particular look at the HPA platform the creator has there. Its an xml based system that may be what you are looking for.

Again you must be the owner/creator/full perms type AV for anything you are going to export from SL but it definitely allows you to extract a build, modify it in Max and then reupload it to the grid.

Now if only there was a reliable translation between Max and Maya that would maintain all the measurements.

Edit: Chosen mentioned it in his post above ... need more coffee this morning apparently.

That sounds very much what I was looking for, although I don't own Max unfortunately. But I'll definitely take a look and see how it works.


Heh, he did, though now I know what it does it gets first priority

First, thank you for the detailed response. You've obviously spent time thinking about these issues already


Excellent, I'll dig in and see what I can get out of those.


That's helpful; I wasn't sure if SL reduced poly counts dynamically at range and/or varied them according to the complexity of the prim (e.g. using more polys to realise a twisted prim). In-world experimentation plus some careful reading of LLVolume.cpp in the viewer source code should help with further figuring out the specifics.


You may be right there... I was thinking in terms of having the correct geometry as a starting point to deform when replicating effects like twist, but haven't spent much time yet experimenting with how to reproduce that in Modo, so maybe it was a bad assumption that it matters.


Yeah, one of the things I was hoping and SL -> modelling environment conversion would achieve is a minimum of messing with UV maps. Ideally, you would only need to edit the UVs to achieve things like things like you describe below:


Thanks again Chosen, you've given me lots of food for thought here and some very useful insights. I'll start by looking at the existing tools you linked and see what I come up with.