The 3D Thread

First of all, here: /54/09/32283/1.html

Since, however, the Scripting Library is not the best place for an at-length discussion on the topic, I'm posting the FAQ/Q-and-A thread here. Feel free to link it through the Building Forums as well, since it's also relevant there.

Anyway, first the front matter. I have worked to the completion of a 3D model importer for Second Life. I say "to the completion" because it works, but others have worked on this before. To not hog the glory, I would like first to tip my hat to those of you that have worked on getting this to work in the past, or on scripts along similar lines. You know who you are. Let's first have a hearty round of applause for all of them.

As for myself, all I have done is connect the dots for you, both literally and figuratively. Since all of this technology was already in existance anyway, all that had to be done was for someone to write a script that would convert vertex and face data into in-world prims. That's what this script does.

Therefore, the purpose of this thread is for you folks to answer one anothers' questions about precisely this, as well as post your screenshots of models you have successfully imported. While I will do my best to provide a working FAQ here, as well as answer any questions you may have, I am only human - and Second Life is not my top priority. But I will try.

Also, flaming, abuse, or otherwise overt attacks on other members' persons will not be tolerated, and I will humbly ask such posts be removed from this thread as needed. If it becomes so bad as to be deemed unsalvagable, I will take steps to close this thread.

Finally, please do NOT publicly release a multi-sim or very-high poly count versions of this script. The current version has these limitations for a REASON - more specifically, to prevent Abuse and Bad Things From Happening.


Now that that's out of the way, let me post the current working FAQ:

Q: How does this script work, anyway?

A: Simply, it's used to convert data commonly known as polygons, converted into "tris" (triangles), into forms that Second Life understands. This means that every face of an object will become, at best, one primitive in Second Life.


Q: How do I use this script?

A: I'll do my very best to provide usable instructions within the script, but this takes a slightly longer answer so... here goes!

Oh, and view the script itself for my program recommendations. I'm fully aware that people have been upset that they might be left out in the cold and be forced to run out and buy a 3D tool or other program now that this works. Worry not - I will assure you that free tools work just fine, because I use them, and believe you me, they work.

Anyway.

1) Create a Wavefront OBJ file using a 3D modeller. Most (90%) of 3D modelling software out there will do this, especially free ones like Anim8or or Blender (I use the former). Make sure that this OBJ file contains no more than 70 vertices (the "v" stuff), 140 faces (the "f" stuff), and 140 texture coordinates (the "vt" stuff). "vn" is normal data - we don't need that here just yet.

2) Using a text editor, open the OBJ document and convert the data into comma-separated strings ("one","two","three". To do this quickly and painlessly, I have provided a Text Macro here for any that need it.

3) Copy the data manually from your editted OBJ document into the scripts provided. The vertex list is used for everything that begins with a "v" followed by a space; the faces lists are used for everything that begins with a "f" and a space. If the compiler gives you an error, don't fret - that just means your list is too long and you will need to move the data after where it's giving you the error into a new list or, at worst, remove it entirely.

Reminds me. Ahem... <allcps>

IF YOU RUN OUT OF LIST SPACE, DO NOT SIMPLY START REMOVING VERTICES OR TEXTURE COORDINATES FROM THE FILE. RECREATE THE OBJ DOCUMENT. BAD THINGS WILL HAPPEN IF YOU DO OTHERWISE.

</allcps> Yes. And as for texture coordinates, that's "vt" and a space again. You'll do the same thing for the new script I will (hopefully) provide for that soon, in the textureUVs lists.

4) Place the "Face Creation Code" into an in-world object. If necessary, name this object "Prim Face." Place your (editted) OBJ Importer code into a second object, and your Prim Face into that object. Raise the new object up to an acceptible height over the ground, Touch it, and watch the fun!

Hope that works for you.


Q: Tris? Why those and not other shapes?

A: A "tri" (triangle) is the smallest unit in 3D design that a modeller will work with effectively to form a face. Think of it as a log in a set of Lincoln Logs, or a lego in a set of legos. Would half a log, or half a lego, be of any use to us? And what are more complex shapes, but a smart combination of those logs or legos?

... bad example. Anywho, it uses tris, and is best used to import models already IN tri form (most 3D modellers will do this for you). I'm working on getting it to do multi-sided faces, but for now, use tris if at all possible.

Xylor was also kind enough to point out that quadrilaterals (four-sided faces) might also be a good idea to make this a touch more efficient for some faces. While I like that idea, I currently have no active plans to edit the code to support quad-based building, because I instead want to take a swing at NURBs imports. Feel free to edit it yourselves if you want quad code.

So, while I intend to allow four-or-more-sided faces to be converted into groups of three to use prims on, I won't be supporting groups of four for use as of this writing.


Q: Great! Does this mean I can import my 30,000 polygon object now?

A: Absolutely not, sparky. Versions I release of this importer script will only support around 120 faces, or for those more into the field, roughly 71 vertices, 140 faces, and (assuming I get it to work soon) 140 texture coordinates as well.


Q: WHAT?! How is this any use to us, then?

A: That doesn't mean you can't import a less intricate model of, say, 1,000 polygons, into Second Life! But, I leave that to you to figure out on the script level - the layman way is to simply import several cutups of the model you want, one by one, in smaller chunks. I'm doing it that way presently, so I personally learn whether or not the process is frustrating.


Q: Does this support NURBs imports to Second Life?

A: Not yet! But I hope to make that a reality as well. Stay tuned.


Q: How about texture coordinates?

A: I'm working on that as of this writing. I'm fairly confident I'll get them in in some form... just expect some delay between when that happens and when it finally goes up to the Script Library. Heck, my "fixed" version of the mesh code isn't up there yet.


Q: Hang on! This code isn't working! What's wrong?!

A: Either you didn't follow the instructions (above), or you're using the old Prim Face code. Unfortunately, the process of getting the (fixed), flawless code up is a little long, so here's a quick solution. In the old code, where it says "iter += 0.01;" or "iter -= 0.01;" - change both of the numbers there to "0.0001" instead.


Q: Oh NO! Does this code mean I'm out of a job as a builder?

A: NO WAY! Builds with this script will be pretty prim-intensive, and as such, very, very limited as to where they'll be. While smart builders with this code can make somewhat efficient works of art, the bulk will probably be inefficient, sluggish, and laggy. Trust me, people will still like you if you build with the existing engine.


Q: Does this mean I can animate meshes as well?

A: Aheh... no. I won't touch that with a 10ft pole unless it's a Linden-supported feature.


Q: I don't buy this. You got a sphere to work - great. How about something more difficult?

A: Certainly.


Q: Can I sell modified versions of this script?

A: So long as the header comments are included, sure. But please, refrain from distributing scripts that can be potentially abusive. The purpose here is to teach people how to fish, not to give them a huge trout to smack other people in the face with.



... enjoy!

Last time I asked you if you were up to any thing cool, I think this should have counted. lol interesting script. is it possible for you to post a data file? that way people can examine the script with out needing to break out a 3d editor?

Already have in the other thread, Kurt.

wonderful accomplishment, thank you for sharing!

can i suggest multiplying your vectors by 256 or another largish power of two before you convert them to strings (powers of two will only effect the exponant and not the mantisa)? you will get better percion (only 6 places for float->string) and it's easy enough to devide out the numbers. The number just needs to be large enough to get the average number greater then or equal to 16.

There is also vector command for cross products in LSL so you don't need to define a function for it.
http://secondlife.com/badgeo/wakka.php?wakka=vector

Strife: Thanks for the suggestion on the multiple of 256. As for the cross product, I know. Whenever the new version of the code makes its way up there, it already has the fix (since I chanced upon a thread about it prior), but thank you for pointing that out.

Actually, I've hit a bit of a speedbump that I could use some help on with UV mapping - and given you recently released that Prim Torture Script, perhaps you can help. Since prims like to mess with textures in ways that don't exactly facilitate UV mapping (that's putting it nicely), I could really use a prim that looks like the attached picture below (obviously, that's not a real prim there).

While I can still make due without, that will mean splitting my tris in two to make due. This is bad, since that'll double the prim count.

Note also that the two texture edges there need to be two separate faces.

Edit: Alternately, if someone knows of a prim fitting the description that will not warp its texture when Top Shear is applied, that would be even better. And for the Lindens listening.... please?

you are going to *hate* me for saying this.
Use the top face of a box. Use cut to manipulate it's shape. I don't know a better way of doing this. This will limit the size of your polygons. Only advantage of doing this is you know that one of the corners is the root of the prim. Cut can be in steps of 0.005 (50 total, don't that suck?)

you have done a wonderful job so far.

Ah yes, the cut approach. I'll entertain this idea once we're able to log into SL again, but I've a lurking feeling this will not be half as easy (or fast) as it sounds, plus it will require a moderate to major code rewrite and severely hinder how large faces can be.

Still, it's a thought to work with.

However, I do have a candidate prim that I'm trying to torture into working the way I want it to: a modified torus, of all things. If that doesn't work, though, I'm more inclined to take the split-tri approach because it'll let us use larger faces in our imported models (at the cost of prims).

Thank you for your suggestions, though. Expect something from me when we can finally log back in.

too bat there isn't a prim type to do just what you want.

YES!!!!! YESYESYESYESYES!!!!!

*kneels and praises Jeffery and all the others who did this before him*

I'm a noob, but ever since I hooked up about 14 days ago, it hasen't gone a single day where I haven't thought 'Man... I wish... Oh I wish... If I ONLY could use Lightwave do model something, the things I coulden't build!!!'

And now, thanks to you and your script, it seems that I finaly can!!!!

ThankyouthankyouthankyouTHANKYOU!!!!

I'd love to write a multi-notecard importer/parser for this, (to make it relatively simple to import any random wavefront obj), but I'm having trouble wrapping my head around some of it.

Particularly where you're generating the face, you pass the one piece of the faces list into the face generating function and then have it generate from there. I see you using the vertex list in there as well, but I don't quite get how you're using it. Heh, I think it's that one thing you didn't want to explain. (It's just kinda important if I'm clearing and generating new lists on the fly since obviously some models will have more vertexes than a single list can hold).

This is a really awesome piece of coding by the way.

As a rough list of what happens in the script, here. It's steeped highly in math, so you might want to look some of this up if you don't know it:

1) Read our faces list which we have placed in the faces (one or two) lists.

2) From there, we determine which vertices each face uses. If there are more than three, we run this a couple times in batches of three. To get our vertices, we look at the first number in each sequence. For example, if one line were to read" f 1/20/10 2/21/11 3/99/68", we would be looking for vertices 1, 2, and 3. If you're wondering, the other two numbers are normals (which tell us which side to flip a face; we don't need that here for now) and texture coordinates (something I'm working on).

3) Now, this is a little tricky. We then sort our vertices based upon how far they are from one another. We do this because the longest edge, by rules of geometry, has the largest angle... and we need that so we don't end up with a vertex where Top Shear of a prim can't go.

4) Once we have our vertices for a face, we pass that to one, and only one, face, and repeat the process.

5) When a face receives vertex data, via a listener, it removes the listener (to conserve script memory and stop taking instructions) and stores the three vertices that it just heard.

6) Next, we see which of our points is the closest to the odd one out, which we have stored as vector3. We do this because we want to form a virtual parallelogram, and the closest side makes for a line that won't cross over or otherwise do bad things.

7) We store the distance between these two points.

We find the final point on our parallelogram by extending a fourth point the same distance we just found. Then we find the center of all four points.

9) Now that we have that central point, we need to find where that exists on the line between vector1 and vector2. We want this because it forms a rough 90 degree angle with our lower line, but moreover, it gives us a distance that would be really handy for finding our center for a Second Life prim. I do this with a loop to find the closest a dot comes on the line, within a 0.0001 margin of error.

And, in hindsight, you just gave me an idea on how to fix a problem I'm having now.

10) Once we have our SL center for use with llSetPos(), we need to find the rotation of our face. We do this with llAxes2Rot, cross products, and some messy code. This is where I just realized an optimization.

11) Finally, we need to find our top shear. We just see how far the top of a triangle is from where we want it to go, and do some math to get it there.

12) Then we shoot the face we just finished into position. There's one. Several more should follow.


... lost yet?

Well, it seems I've run out of time on this script for now. Here's the current beta with UVs for you to toy with.

I'm also going to submit a bit of non-texture, but optimized, code to the post in the Script Library as well. The fixes will be listed there.

As for the beta, the UV Reader and Vertex Reader are both scripts to go in the parent object. The other two go in a prim to be placed inside of the parent.

can we get a demostartaion of this script and how it works in game im sure manny would like to see it and to see its capabilities its one thing to read it but another see it in game.

*blinks*
Did you even try running it before you posted?

Wha...? Well, this thread is a golden oldie.

Byron, didn't you see the 3D model I rezzed earlier in Nexus Prime? I think you were right in front of me at the time.

And yes, the script should run a test sequence "out of the box."

Iveposted a version of Jeffrey's rezzor that reads from a notecard instead of a list in the script library, but it still might not have been approved. The one attached to this message is slightly newer then the one posted to the script library though. Strife's post about inventory changing keys upon save sparked a new way to ensure the vertice cache's freshness. (see the script if Im not talking sence ). I will update the one in the library as soon as it is approved by Nada. Theoretically, this script should allow for models consisting of an unlimited number of vertices, though it is limited by the size of notecards (64k I believe). See the library post for more details.

Jeffery, your scripts are amazing. Though, Im still figuring out the part where you make faces consisting of > 3 sides into multiple faces of 3 sides.
==Chris

For that, I just did some tests to figure it out by hand.

Basically, vertices in an OBJ are defined in a set pattern, where each additional one connects to the last. All you need to do from there is figure out how to connect the triangles.

I'll be sending you the quad version I did as well. Never quite managed to release that.

Is the polygon allowed to be concave?


w00t

Because I don't include "normals" definitions in the program, yes. It works well enough for now.

It seems to me like I did everything correctly. I have two scripts and two objects. The Prim Face cube has the Face Script in it which I put in my inventory, then I created a 2nd cube with the OBJ script then I drug the prim face cube out of my inventory into the content folder of the 2nd cube in with the OBJ script. However, I can't touch it =/.

Any suggestions, or am I doing something horribl horribly wrong?

Try compiling the script again. Failing that, make sure the land you're on isn't "no script."

How exactly do I compile the scripts?

Hm? You should be able to pop them open. Hit the spacebar somewhere that doesn't break anything and choose "Save."