Talk:Sculpted prim

Woot ^_^ thx. -- Strife Onizuka 14:45, 27 April 2007 (PDT)

/me adds additional Woot! ;-P --AlisonW 15:42, 27 April 2007 (PDT)

Of the ways of incorporating mesh into SL this is by far the most sane. Mind posting some example textures? Frame based llSetTextureAnim would be cool too. -- Strife Onizuka 12:04, 27 April 2007 (PDT)

The textures for the shapes shown in the demo are posted in Torley's flikr stream. [2] I haven't got Maya but I'm making a few basic architectural elements in 3ds Max, I can post them here if anyone wants to convert and play with them. Elle Pollack 17:10, 27 April 2007 (PDT)

I'd like to see a wireframe of the default sculptie prim (in the client > rendering > wireframe menu or ctrl shift r, one can show wireframes) Would give me a better idea of how to approximate it offline, to get a better feeling of what the possibilities/limitations of the prim are. Of course if rev 2 is around the corner, would like to see that wireframe too :D --Hypatia Callisto 11:19, 29 April 2007 (PDT)

The new preview is out! Go forth and sculpt! Elle Pollack 10:04, 5 May 2007 (PDT)

Strife's Observations

I've been examining the video posted on the blog. I took screen shots of the textures shown in the texture picker, giving the advantage of being able to see the rendered texture and compare it to real prims and their sizes.

I'm a little fuzzy on this part. It's on or the other
A)The values are centered so if you want a small dot you have to use an image that 127 or 128 grey.
~~B)The values are related to the base sphere.~~
The default shape is a sphere half the prim size.
I think the bounding box is the size of the base sphere, meaning the mesh can be 3 times larger then it's bounding box.

Strife - the answer is A - point position is relative to the origin - scaled by the prim size. --Qarl Linden 19:49, 27 April 2007 (PDT)

Ah good thats what I thought but was getting confused by some of the images i was looking at. If this is the case it shouldn't be too hard to build a modeling tool in C#. -- Strife Onizuka 08:06, 28 April 2007 (PDT)

So the form is defined by the vectors from the origin and assumes a closed shape. What about a non-closed surface? We don't have prims which are Planes, but there's been arguably little need. Now such a primitive would allow more highly-detailed models which don't require closed forms (e.g. sheetmetal shapes for vehicles). Any plans on adding such a Prim to the library? -- Csven Concord 09:12, 28 April 2007 (PDT)

yes, rev 2 will include "plane-like", "cylinder-like" and "torus-like" shapes, to compliment the "sphere-like" shape. (basically, all permutations of open/closed on the ends.) --Qarl Linden 09:39, 28 April 2007 (PDT)

Once these are implemented, presumably it would be possible to adapt an export script to slice a large/detailed model into smaller chunks that could be pieced together in-world? --AJ DaSilva 10:56, 29 April 2007 (PDT)

AJ - yes. one issue here is the 8 bit precision on images, and the jpeg compression applied to the data. we chose the name "sculpted" to convey this idea of "approximate" shapes - but as you can see from the plate in the plate of fruit, "approximate" is pretty close to "exact". furthermore, it wouldn't be hard to support 16bit images and higher precision jpeg compression - but let's first see whether we need it. --Qarl Linden 12:50, 29 April 2007 (PDT)

LSL functionality?

Was wondering if there are plans to put in an LSL function to allow swapping out of the sculpt texture. This would be a nice scripted way to morph the shape through a script. This would be very useful for AV attachments (hair, tails, wings, etc.) to cut down on prim usage as the script could just morph the shape of a single prim. Or perhaps it could be applied to the AV itself (Can you say werewolf transition)? A more advanced version would make it shift between the old and new textures more smoothly rather than a sudden shift (or have an argument to specificy a 'hard' or 'smooth' morph).

I definitely like the idea of sculpted prims. However--

1) LL should embrace open source/cross-platform solutions. Embracing Maya first (as one of the most expensive platforms) seems out of place.

2) Sculpting tools like Silo and Modo should be considered. Ideally a utility program that can convert a specified .obj file (an almost ubiquitous 3D file format) to the textures for a "sculpted prim" would be ideal. This would allow content creators to use their tool of choice and then process the .obj of their sculpture into the appropriate "normal" maps for SL.

3) Guidance on linking of sculpted prims to create large sculptures than a single prim should be considered. (From reading the technical information about texture size, I get the sense we're looking at some level of subdivision of a single cube --perhaps 8x8x8 that is then deformed by the maps.)

As I understand it, they did maya first because that's what Qarl knows how to do. He learned the think while working on the 2nd and 3rd Matrix movies. Elle Pollack 18:17, 27 April 2007 (PDT)

right you are, Elle. --Qarl Linden 19:51, 27 April 2007 (PDT)

What avenues have been considered for this morphing mentioned on the sculpted prims page? Some kind of interpolation between one texture and another? Or will it be akin to texture animation as we have it now? If it is interpolation between separate textures, will there finally be a llPrecacheTexture(...) added so you don't get a "blurry" object to transition to? ^.^; --Feynt Mistral 21:31, 28 April 2007 (PDT)

Feynt - our idea is to extend the media feed to inject it into the sculpted texture. there are various projects at LL to extend the media type from just quicktime to flash and html - so as these projects complete, sculpted prims will become more and more powerful. --Qarl Linden 12:52, 29 April 2007 (PDT)

There are a so many problems that need to be dealt with before media streams can be used to control textures, let alone prims. Once you start importing content that intimately into the game you open up all kinds of performance, security, reliability, and privacy issues... I think we'll see Havok 4 before we'll see SL handling a dozen streamed textures in view at once, and we'll need to be able to handle a couple of dozen animated sculpted prims on the screen at once without lag if they're going to be widely used. Before depending on streams to morph prims, how about extending the mechanisms already avilable for textures in-world to the prim texture: let the script scale, rotate, shift, and animate the texture. -- Argent Stonecutter 13:43, 29 April 2007 (PDT)

Argent - scale/rotation/translation have little/no meaning for sculpted textures. animation, tho, is something to consider. --Qarl Linden 13:44, 30 April 2007 (PDT)

Are any LlSetPrimitiveParams rules or Prim functions incompatible with sculpted prims ? --Simil Miles 04:55, 4 May 2007 (PDT)

well - they can't be flexi. otherwise, no - i think all the rest should work. --Qarl Linden 14:50, 4 May 2007 (PDT)

PRIM_TYPE_SCULPTED

How about a PRIM_TYPE_SCULPTED paramater for the ll(Get|Set|SetLink)PrimitiveParams functions?
Syntax for Set: [PRIM_TYPE_SCULPTED, key sculp_texture] -- Strife Onizuka

that is exactly what we've done. --Qarl Linden 19:51, 27 April 2007 (PDT)

Warning : In the script editor it's PRIM_TYPE_SCULPT, not PRIM_TYPE_SCULPTED ! --Simil Miles 09:43, 5 May 2007 (PDT)

You mentioned above different base shapes, so i take it you will be using a PrimitiveParams format like...
[PRIM_TYPE_SCULPTED, integer style, key sculp_texture]
or will you have a different PRIM_TYPE_* flag for each style? Strife Onizuka 14:11, 28 April 2007 (PDT)

Strife - haven't thought about it yet. i'm trying to get rev1 under control, first. :) --Qarl Linden 12:53, 29 April 2007 (PDT)

The full parameter list should be in there, even if rev1 ignores everything but texture, so that scripts don't break. Otherwise you'll end up needing PRIM_TYPE_SCULPTED_SPHERE, PRIM_TYPE_SCULPTED_CYLINDER, etcetera...

Should also make room for some way of switching shapes without downloading a new texture, similar to texture-switching and texture-animation.

Suggestions

[PRIM_TYPE_SCULPTED, integer base_type, key sculp_texture, vector texture_scale, vector texture_offset]

Allow for multiple shapes in a single texture map, using the scale/offset technique used by tools like XYtext.

[PRIM_TYPE_SCULPTED, integer base_type, key sculp_texture, integer rows, integer cols, integer index, float rate]

Allow for multiple shapes in a single texture map, using the scale/offset technique used by texture animations. If rows or cols == 0 the whole texture is used, if rate==0.0 no animation occurs.

--Argent Stonecutter 13:51, 29 April 2007 (PDT)

Sculpt Texture

Sculpties are now live on the beta grid (1.16), it's time to think about Sharing_sculpt_maps_and_textures.

As a graphic artist, I'd like to do thing manually on Photoshop for finer details when need to do quick minor changes.
Can you tell what each color and greyscale value by pixels actually do to each mech points? --Vincent Nacon 21:00, 27 April 2007 (PDT)

The images are three colors (RGB) much like normal maps. Each pixel defines an X/Y/Z (coded with R, G, and B channels) offset from the origin (center of the prim). I doubt you would have much luck touching up something like this in Photoshop, you might look at something like ZBrush when we get an exporter for it. Eddy Stryker 21:17, 27 April 2007 (PDT)

That I did understand, but I really want to go into great depth of understanding it. I like facing challenge when I can't use 3D Max, Lightwave, or even Maya. ;)

(I don't even like Zbrush O-o, those are more for bumpmapping and texture skin.) --Vincent Nacon 22:21, 27 April 2007 (PDT)

Vincent - the color values map to vector values in exactly the same way as "normal maps". in a nutshell: the color black (0,0,0) maps to the bottom-left-back corner (-1, -1, -1). the color white (1,1,1) maps to the top-right-front corner (1,1,1). red (1,0,0) maps to the right center point. perfect gray (0.5, 0.5, 0.5) maps to the center (0,0,0). and so on. --Qarl Linden 13:00, 29 April 2007 (PDT)

Since each pixel represents an offset from the center of RGB to XYZ, does that mean that the order of pixels does not make a difference? For example, swapping the colors between the first and last pixel in an image still results in the same exact object. --Dedric Mauriac 00:22, 3 May 2007 (PDT)

The position of the pixel within the sclupt map determines which vertex of the mesh occupies that XYZ position in space. While you could randomly re-arrange the pixels within the map and end up with verts in the desired locations, the polygons connecting those verts would go all over the place. To use a humanoid mesh as an example, you might end up with a polygon connecting the left hand, right toe, and chin, another connecting the nose, left elbow and right knee, etc. As someone who's converted meshes which accidentally got then vert indexes shifted when assigning polys to them, let me tell you, it ain't pretty. ;) --Deanna Trollop 04:51, 3 May 2007 (PDT)

Zbrush is for way more than texturing - I make all my mesh morphs with it and it's what I originally bought it for. Only when I started playing SL heavily did I start using it more for texturing :D Actually, this is really a lot like how the pixols in Zbrush work, I sometimes start with a Zsphere and just start sculpting with my tablet. Can't wait to get a Zbrush export - I'm drooling to get my hands on this feature. I'm starting right now on making zsphere stuff in the anticipation of making them into prims :D --Hypatia Callisto 07:48, 28 April 2007 (PDT)

I'ld like to make my in-world tool compatible with this type of prim, is there a sculpt texture UUID available on the main grid ? - the default one would be perfect.--Simil Miles 23:33, 27 April 2007 (PDT)

Torley has been putting textures online somewhere... not sure where... --Qarl Linden 09:41, 28 April 2007 (PDT)

On her flikr stream. See the link I did way at the top of this page. Elle Pollack 10:19, 28 April 2007 (PDT)

I'ld need the UUID of an in world texture...--Simil Miles 13:24, 28 April 2007 (PDT)

Simil - you can take Torley's textures, uplaod them, and find their UUID, yes? am i missing something? --Qarl Linden 13:00, 29 April 2007 (PDT)

- Hm ok I can do that until it's on the main grid, but which one did you choose as the default ? the cube the apple the banana or the mushroom ? --Simil Miles 11:58, 30 April 2007 (PDT)

-They won't be "system textures" at this point, and I don't know if they will be...we'll see what happens on Preview I guess? Elle Pollack 15:14, 28 April 2007 (PDT)

I'm afraid that default sculpted prims won't render or will render as sphere if they don't have a default sculpt texture.--Simil Miles 19:10, 28 April 2007 (PDT)

Will we be able to preview rendered sculpted prims ? (Don't want to waste L$10 on every fix)--Simil Miles 06:20, 28 April 2007 (PDT)

yes, the texture upload preview has a "sculpted prim" mode. --Qarl Linden 09:41, 28 April 2007 (PDT)

I understand the basic idea, and I understand NURBS very well, but I'm having a hard time putting the pieces together... If this is NURBS-like, can you control the finer points of the shape with a knot vector? Also, can you give a brief desciption of how the texture is actually encoded? In other words, is there a defult way that the sculpt texture is mapped to the prim surface, or is that tweakable with the UV settings? --Keyser Swindlehurst 07:48, 28 April 2007 (PDT)

not sure what you're asking Keyser. --Qarl Linden 13:00, 29 April 2007 (PDT)

I think I might have figured it out after I asked, but the first question was basically; does the texture contain control points for a NURBS surface (in which case, a full NURBS implementation would also need weight vectors and knot vectors), or does the texture simply contain displacement points that were generated by another tool (where the modeling could have been done with or without NURBS). I'm assuming it's the latter, yes?--Keyser Swindlehurst 17:50, 29 April 2007 (PDT)

Keyser - you are correct - it is the latter, not the former. the reason i talk about NURBS so much is that sculpties are closely related to them (both being parametric surfaces) and they share a lot of properties - and NURBS are familiar to many modelers. --Qarl Linden 21:34, 29 April 2007 (PDT)

Are there plans for the alpha layer to figure into sculpted prims (such as weight)? --Dedric Mauriac 00:52, 3 May 2007 (PDT)

See the Flexible section for discussion of what the alpha channel might be used to represent. --Deanna Trollop 04:51, 3 May 2007 (PDT)

On a different topic - I think I understand the reasons why you chose this direction (you already have support for textures, etc.), but I'm wondering if it will be the best approach in the long run. For instance, I'll make the prediction that many sculpted primitives will be "heavier" than need be, both in terms of texture size and vertex count. Also, the lack of real texture coordinates, etc. is somewhat troubling in the long term. As for morphing; there are many skinning/morphing techniques that don't rely on image-based vertex positions. Finally, the JPEG questions are what started me on this line of thinking - the features that make JPEG work visually don't hold up that well for numerical data, as we've seen with normal maps and other "data textures". It might work well for a lot of prims, but JPEG isn't a great vertex compression tool. My goal is not to be negative, but I'm just curious if you see this as a long term direction or a short term stepping stone.--Keyser Swindlehurst 19:47, 29 April 2007 (PDT)

Keyser - a fair question. let me address the points i disagree with first: (1) sculpted prims may be heavier than their progressive mesh counterparts - but will be significantly lighter than the existing prim usage (have you seen how many primitives are in prim hair???) (2) i don't see why you feel they don't have adequate texture coordinates (3) yes, of course there are morphing techniques for all model forms, however i wouldn't call them "trivial" like using iMovie to create a blend (4) we use jpeg2000 for our texture compression, i.e. wavelet compression, which is used successfully in all sorts of geometry compression.

that said - yes - i share your concern. the fairest answer is that only time will tell. --Qarl Linden 21:45, 29 April 2007 (PDT)

Thanks - forgive me if I come across as argumentative. It turns out that this approach is a mix of a few subjects that I'm interested in, so I'm curious to poke a bit more. Bear with me :) Keeping with your 4 points:

1) Yes, they will be lighter than the existing approach, but one could argue that the existing approach is bad enough (for really complex meshes), that the comparison isn't even worthwhile. Again, I understand your design constraints/considerations, so perhaps I'm being unfair. 2) I come from a graphics programming background, so I'm used to having a high degree of control with texture coordinates and all other vertex data. Going forward, an approach that *only* lets you specify position is probably going to be limiting, and certainly prevents you from packing other data into the vertices (anything from normals to bone weights, etc.). Again, it probably isn't a big deal for now, but I'm trying to imagine the path that gets us from SL as it is now to a "modern" 3D app with things like postprocessing and (eventually) geometry shaders and other new features. 3) Interesting - here was my thought process: I was thinking that an interpolated morph between two meshes would be as simple as two meshes and a multiplying factor. For the iMovie blend, you have to create two meshes, encode them as textures, and generate successive frames, which would be heavier in terms of assets than the two meshes and also require more tools in the pipeline. In other words, I'm thinking about a simple Quake2 style vertex interpolation between two meshes, which would be made heavier if you used a blend movie. For something more complex, like skinning, the texture approach might be an interesting way to encode a complex animation without the problems of linear interpolation or th complexities of dealing with bones, but you would also lose the flexibility of a true skinning system. 4) To be honest, I don't know a whole lot about how well JPEG2000 works for geometry. The few papers I've skimmed seem to show that it does, but it looks like they tweak things slightly, either not treating it as just any other image, or going to the lossless mode. It will be interestng to see! In any case, I'm looking forward to playing with this. Thanks!--Keyser Swindlehurst 10:53, 30 April 2007 (PDT)

Texture size can be considered a moot point, it's been stated that textures need only be 64x64, and any larger won't help. It can be hard clamped so that when you upload only textures 64x64 or smaller will be accepted, or it can be set so that sculpted prims won't accept a texture larger than 64x64 (ultimately getting a lot of "why won't my 1024x1024 texture work for sculpted prims?!11" questions). -- Feynt Mistral 21:34, 29 April 2007 (PDT)

3D Programs for the Rich and...the not so Rich.

(Discussion moved to Talk:Sculpted Prims: 3d Software Guide. Elle Pollack 09:04, 8 May 2007 (PDT))

"Annoying" Questions

Distance from prim center is no more than 5m? (10m from side to side.) --Vincent Nacon

yes. --Qarl Linden 09:52, 28 April 2007 (PDT)

No hollow and holes or even cuts? --Vincent Nacon

see my comment above about the future "torus-like" topology. rev2. --Qarl Linden 09:52, 28 April 2007 (PDT)

No Custom UV mapping for the (image, not model)texture itself? (unless given from plugins) --Vincent Nacon

well - depends on what you mean. you can still use the texture scale/rotate/offset controls to position the textures. but no - the sculpt texture itself defines the texture space, if you know what i mean. --Qarl Linden 09:52, 28 April 2007 (PDT)

Mass?

similar to physics - the sculpties are approximated on the server as a flattened sphere. so whatever mass that produces is what the sculpties will have. (again - we're considering how to put sculpties into the physics engine - we've done tests and they work well - there's just the unpleasant need to have sims load textures.) --Qarl Linden 09:52, 28 April 2007 (PDT)

I assume this means that any kind of animated prims would have to be phantom. --Argent Stonecutter 13:55, 29 April 2007 (PDT)

Setting to place prim's center-point offset? (doors that rotate at one side instead of from the center) --Vincent Nacon

ah - interesting. perhaps, yes. in the meantime - your exporter can be modified to produce a door which isn't centered. or sheesh - this kind of thing might be possible by photoshopping the sculpt texture... hm. --Qarl Linden 09:52, 28 April 2007 (PDT)

re: Photoshopping sculpt textures... this is just mental theory, but I'd think the following procedures would apply:

- To scale along a given axis, keeping the positive/negative end of that axis fixed:
  - Levels, increase shadow/decrease hilight value of desired channel, respectively.
- To shift the entire model along a given axis:
  - Increase or decrease brightness of the desired channel. (Note, values that get "clipped" to pure black or pure white will cause the associated verts to "squish" against the side of the bounding box.)
- To mirror-flip the model on a given axis:
  - Invert the desired channel (transposing the verts on the + side to the - side, and vice versa) AND mirror-flip the image horizontally or vertically. (Skipping the second step would end up with a model mirrored and turned inside-out, because the vertex order of the polys would be reversed, similar to a 180 twist on a prim sphere)

--Deanna Trollop 23:36, 28 April 2007 (PDT)

Deanna - yes, EXACTLY so. --Qarl Linden 13:25, 29 April 2007 (PDT)

Another thought, regarding photoshopping

The following scheme came to mind, as a way to create a bump on a sphere in any direction. I don't think it would work exactly as I've laid it out, but soem such scheme where you use the math-like operations in adjustment layers on maps should be useful... any thoughts?

Create a layer containing the "unit sphere" map.
Duplicate it
Create a mask containing a fairly blurred greyscale blob.
Create a multiply adjustment layer using this mask.
Apply the multiply layer to the duplicate sphere layer.
Add the layers.

--Argent Stonecutter 13:26, 2 May 2007 (PDT)

* Allows flexiable? (I doubt it anyway) this was answered in the faq, flexiprims will be implemented, just not in the first release.Charismo Abismo 08:04, 28 April 2007 (PDT)

yes, we're thinking about how to do the flexible version. currently - flexible objects have a 1-dimensional spine that drives their motion - i'd like to make the sculpties a 2d spring system (if possible.) also - we have this unused alpha channel, which would be perfect for adding flexi information (how stiff/springing is this section of the object, etc.) --Qarl Linden 09:52, 28 April 2007 (PDT)

I came aware that TGA takes more memories than JPG2000 format, should it support both anyway if not using Alpha Channel for flexi? --Vincent Nacon 17:21, 28 April 2007 (PDT)

Vincent - internally all image types are converted to jpg2000. --Qarl Linden 15:18, 29 April 2007 (PDT)

What are the polygon faces limit? Does it even resist texture going more than the limit, say a 1024 texture? (yes, going over 10,000 faces would be insane, I'd think?) --Vincent Nacon 17:14, 28 April 2007 (PDT)

Vincent - regardless of texture size - the maximum tessellation of the sculpted grid is 32x32. larger images are simply down sampled. --Qarl Linden 13:25, 29 April 2007 (PDT)

I may be the first to complain about it, I think that's too small. 32 x 32 = 1024 vertexs Maybe 64x64(4096 vertexs)? Any higher than 128 would be too much. --Vincent Nacon 14:20, 29 April 2007 (PDT)

Vincent - no. 1000 verts is roughly the render weight of our heaviest prim. if we allowed more verts, we'd need to implement some kind of prim weighting mechanism to even the load, which is all around unpleasant. if you need more detail, use more prims. --Qarl Linden 15:16, 29 April 2007 (PDT)

In case of a "fool" using an real texture that wasn't made for sculpted prim, how would it react? Anyway of prevention of using non-sculpted image? I could even image an bizarre result that could lead viewer client-side crash upon rendering. --Vincent Nacon 17:21, 28 April 2007 (PDT)

Vincent - yes. my word for this is "vertex vomit"... and no, it's not pretty. but there's no danger of client-side crash - just client-side nausea. --Qarl Linden 13:25, 29 April 2007 (PDT)

What's the word on JPEG compression artifacts skewing the vert positions? --Deanna Trollop 23:07, 28 April 2007 (PDT)

excellent question! we specifically want JPEG2000 (wavelet) compression on our vertex data for the same reason we want it on our texture data - efficiency. however you're right, this may lead to undesirable behavior as well. we're taking a wait and see position here - once people have built many sculpted prims, if there's a need, we may start tweaking our compression levels (and add support for 16bit textures, as well.) --Qarl Linden 13:25, 29 April 2007 (PDT)

(Guess I need to move this down here so it gets seen) I'm wondering about UV maps too...I think it boils down to if you have UV map data in a model and you export it into the (what are we officialy calling them, sculpt maps?), is the UV mapping preserved? (Qarl had to get those textures aligned on his objects *somehow*...)Elle Pollack 11:50, 28 April 2007 (PDT)

Elle - sorry. :) yes, this wiki format is less than ideal for conversation... to answer your question: the sculpted prim will have the same UV space as the object in your modeling program. the UV space and the shape of the sculptie are intrinsically linked. --Qarl Linden 16:08, 29 April 2007 (PDT)

Is anyone working on a 3ds Max exporter? I know it mentions it will be done just wondering if works started. Dimentox Travanti 11:57, 2 May 2007 (PDT)

Not to my knowledge (as the only 3DS Max user I know that's been following this, who doesn't write code ;p). Your best bet in the meantime will probably to export the model and make the sculpt map in Blender. Elle Pollack 10:33, 4 May 2007 (PDT)

~~: Also: what is the absolute biggest size a sculpted prim can reach ? 10 m ? 30 m ? 5 or 15 m from the origin ?~~ Anwsered: 10m from side to side, 5m from center.

Test Fodder for the Maya Plugin

In the wild, under Creative Commons: http://www.themindstream.net/slmodels/ - 3 objects (one in 3 parts) with possibly more to come I'm still in a technical "out of SL indfinately because of computer issues" mode, so if any of these make it as far as Preview, I want screenshots! If there's an issue with any of the models that prevents their working, IM me through SL with details. (I still get and can respond to those). Update: I found that I had to fix some things on the pillar top and bottom; you may wish to re-get these. Some new stuff added too, and will be periodicly for a while. Elle Pollack 23:58, 27 April 2007 (PDT)

ah nice. i didn't look closely - but remember you REALLY want to use single NURBS surfaces for your models - otherwise the conversion process can be painful. --Qarl Linden 09:56, 28 April 2007 (PDT)

Elle, I tried importing/exporting your models for you, these are the results: http://www.flickr.com/photos/8019908@N02/ THey look a bit strange to me and with no way of testing them, who knows? But the exporter seems to work ..... NOt sure about the black areas, they look scary! RamessesIII Pharaoh 07:05, 30 April 2007 (PDT)

- Iiiiiinteresting...will have to see what happens when the tools go live in preview. In the meantime I've done a bunch of non-standard primitive shapes (pentagon, hexagon, octagon) that I'll upload later (those will be released to public domain, I'm not about to try and reserve rights on basic geometry) and trying to figure out what it takes to recreate those shapes as NURBS objects (joining surfaces is finiky, trying to get sharp corners is downright painfull x.x). Elle Pollack 12:25, 29 April 2007 (PDT)

mmmmm.... I had a look at those shapes and tried export, they look wrong but like it says, this works best with organic shapes, and i have found that polys from other programms do not seem to export correctly, especially inorganic ones. (hence the black areas). I managed a basic nurbs banana and other silly shapes, basically by deforming a sphere, as the sculpties are based on this? Anyway, all the organic shapes and some with pointy bits look ok after export. I will post some of the textures for info see flickr link above (perhaps with before and after this time). I also have to say that, having looked at the output results (and I am no expert), the concept that any human could produce these textures visually in Photoshop quite extraordinary, I remain to be proved wrong of course. RamessesIII Pharaoh 07:05, 30 April 2007 (PDT)

I shall have to learn myself some NURBS than...s'what I get for being a novice game modeler. I did try to follow the guidelines for polygon objects mentioned in the FAQ. However they'll still be usefull for testing, the process of figuring out what works and what doesn't. Elle Pollack 10:23, 28 April 2007 (PDT)

NURBs are quite a bit different than poly's. I'd started a tutorial to show Industrial Designers on the Core77 forum how to make single-surface models using Maya/Alias Studio. It's actually relatively rare but I prefer them bc they import into CAD cleanly. Not sure I still have it and the associated images, but if I do I'll post them. -- Csven Concord 17:50, 28 Apr 2007 (PDT)

That big black area you should probably photoshop gray otherwise you will have pollygons in on of the corners. What would be better would be to crop off the black areas and resize the image up (it won't effect the rendering except to give you better detail). Strife Onizuka 20:18, 28 April 2007 (PDT)

MEL Broken?

has anybody got the script up and running? I am having trouble with it. pasted it but I am getting syntax errors all the way:

// Error: if (size($parents)†!= 0) // // Error: Syntax error //

Have no idea what to do. This is definitely a revolution.

Ok, I have it, the cross has to go. I'm not sure how that works in this Wiki or any Wiki for that matter but it would be good to be able to edit the MEL. Managed to generate one of those colour depth maps (or whatever they are called) this is looking fantastic! :-)

hmmm... didn't see that plus-sign in the wiki page - perhaps your cut/paste had a problem? (line break, etc?) --Qarl Linden 09:57, 28 April 2007 (PDT)

indeed I can't see it either now :-) Mac and Safari I suspect.

Error in the mel - or not?

I got this error when executing the mel script:

exporting sculpt map for nurbsCylinder1 into file simple_column.bmp // Error: Object list must contain a surface and a texture //

Um.. a texture? Surface I have, but nothin' said nothin' about having to texture map it first...

Maya 7 Unlimited full version / Mac 1.67 Ghz PowerBook G4, blah blah - GC Continental 12:25, 29 April 2007 (PDT)

Oh well... At US$7000 for Autodesk Maya I don't think I am going to be using this feature any time soon, unless of course someone is willing to pay L$2000000 for a mushroom.

People keep refering to US$7000 version of Maya. That is the "Unlimited", most expensive version. Last I checked, the low-end but very capable version was still US$2000. Expensive but quite a bit less than the number people are throwing around. -- Csven Concord 17:44 28 Apr 2007 (PDT)

- I don't know the specific way of doing it in Maya but try applying a basic default UVW Map: Box maps, face maps and sometimes cylinder maps are probably the best general purpose ones. Planar maps, maybe, but they can also be applied within SL. In general, you should test maps out with a basic texture like a checkerboard to check the repeats and avoid nasty stretching and deformations. Elle Pollack 14:48, 28 April 2007 (PDT)

Yeah I got the same error, for some reason Maya doesn't see the cylinder part of the nurbsCylinder as nurbs so the MEL script doesn't see it either. if you select the caps of the nurbsCylinder then the MEL works. Strange but true :-)

I suspect the problem people might run into (and the capped cylinder is probably a decent example) is in thinking of NURBs primitives, patched surfaces, or "attached" surfaces as single surfaces. They may not be. If the script is looking for a single surface, then it likely needs to be a single surface; not a collection of surfaces combined into one shape (kind of like how a set of prims together comprise an "object"). If the surfaces have been created individually and "attached", then they probably need to be rebuilt as a single surface. Thus, I wouldn't expect a capped cylinder to work because it's three surfaces; not one. Another way to create that cylinder is to create an uncapped cylinder, then add some isoparms on the cap edges, and then pull the form closed (like cinching a sack). The more isoparms on the cylinder edge, the sharper the corner. Give that a try. -- Csven Concord 18:12, 29 April 2007 (PDT)

-- What you might also like to try is drawing a CV curve of one half of the 'cylinder' and revolve to get a single surface. Worked for me, I think. I am a newbie to NURBs, (loving them though), does that make me a NURBIE? RamessesIII Pharaoh 14:31, 30 April 2007 (PDT)

- I think you're right, Csven. With a single lofted surface it's just fine. It's gotta be the caps. Well, I *do* get this error: "// Error: No object matches name: loft2.boundingBoxMin //". Kinda funny, but hey, I got the bitmap! Now all I need is a client that I can test this with.... GC Continental 17:50, 29 April 2007 (PDT)

Caps exibit a similar behavior in 3DS Max, a fact which has been driving me batty trying to get the hang of these. x.x Elle Pollack 23:35, 29 April 2007 (PDT)

Tutorials

I know there are probably tons of tutorials out there on how to do the basic process of what's needed for sculpted prims (3D app user wise). But if someone would want to find a really good one, or write one specificly for SL that would be most handy to pass around to people once this goes into Beta then live.

I say this now because it's best to be prepared than to be scrambling for it later on. :)

Oz Spade 14:14, 28 April 2007 (PDT)

This might get you started [3] Eddy Stryker 22:10, 28 April 2007 (PDT)

Here's some stuff that could be the start of a guide: Sculpted Prims Creators Guide Elle Pollack 00:34, 30 April 2007 (PDT)

Sculpted prims in Blender just started looking a whole lot easier. [4] Elle Pollack 13:16, 5 May 2007 (PDT)

An almost complete method to export almost anything from blender camilla Yosuke 9 may 2007

Further tips on Blender ( note use of UV mirror rather than inverting X on texture ) [5]

3DsMax Tutorial for sculpt prim forum thread

The Future: beyond the first release

Qarl, you already mentioned a rev 2 with more features. Are you going to keep working on this project after the initial release, or doing something else and hoping you get back to it a later time? Just asking, because projects have been abandoned before after a hopeful start. Frans Charming 00:23, 29 April 2007 (PDT)

Frans - i hear you. i can't promise i'll remain focused on sculpties for the rest of my life - but i can promise that i'll continue improving our SL. and for the foreseeable future - there are still many things i want to accomplish with sculpties. --Qarl Linden 14:02, 29 April 2007 (PDT)

Another question, however implausible, would this technique be applicable to avatars? I can't imagine how many furries would love to replace the human avatar with a custom mesh (myself included). Of course the first major obstacle to that would be figuring a way to map vertices to animations currently used by SL. --Feynt Mistral 01:04, 29 April 2007 (PDT)

yes. there are those at the lab who are looking at this very closely. --Qarl Linden 14:02, 29 April 2007 (PDT)

- I think the first step in applying these to avatars is going to be as standard attachments...face, paws, claws, tails, and yes even *those* attachments "down there". My sideline being anime/cosplay AVs, I'm allready envisioning a mask of sorts that would get the "big eyes, small mouth" of anime characters much better than AV sliders can do. The nest step would be animation, probably a series of different "keyframe" models and script calls to swap out the sculpt textures. Full-body replacement meshes to swap out for the default are not likely to be doable with this. Elle Pollack 12:42, 29 April 2007 (PDT)

Sculpted prims don't directly address the problem of animating objects (though using a flash animation etc as the Sculpt Texture might). If you go back and view the video again, you will see there is a one frame load time associated with these mesh. This is an issue that will need to be dealt with before changing sculpt textures is a viable method for animating objects. Continuing on this, anyone who has built an av of prims knows that clothing is a problem, it has to be custom made for the av. As to further customization of the av, LLs unlikely to do it because of bandwidth reasons. The current av mesh and skeleton are about 4 MB and have to be loaded into memory. If users had custom avs of equal or greater detail we would be seeing a much more CPU, GPU, memory and bandwidth intensive SL; better to wait a 3 -> 5 years for the hardware to catch up. -- Strife Onizuka 13:05, 29 April 2007 (PDT)

For some reason the fact that the UV map changes with a change to a mesh always seems to be the last thing I think of. I didn't really think of the impact it'd have on clothing, which you're right it would definitely require custom work with every new mesh (unless SL somehow gains advanced 3d controls to allow custom texture stretching, which I don't see happening any time in the foreseeable future). I think being able to hide the human avatar would be nice though for those who do want to tackle the task of using these prims as replacement parts. Invisiprims are great and all, but they have been broken before and they do tend to be obvious if you know what to look for.

In response to the load times for the textures, you're right, which is why I had asked in another section about an llPrecacheTexture function. Argent brings up a good point I had also thought about, allowing texture animation for scripted prims (like the blink scripts for most furry heads) that swaps between a set of frames. It could mean long load times for some animated prims though if there isn't some kind of interpolation built in for 'tweening the frames, as people would probably try doing 512x512 textures to smoothly animate stuff. -- Feynt Mistral 14:05, 29 April 2007 (PDT)

For a four stage animation, there wouldn't be any advantage to using more than 128x128 or 64x256 (depending on the scheme). This does assume we're talking about small animations (raised eyebrow, for example, or a slight ripple effect on a surface), or that (as Feynt suggests) "tweening" animations are available. For situations where you're "morphing" between multiple mostly-static states (opening furled wings, for example) smooth transitions would probably be unnecessary... the shapes are just too different. -- Argent Stonecutter 10:11, 30 April 2007 (PDT)

I would agree on most of it. I too wouldn't see the point for more than say, 4 to 6 frames (for different facial expressions) if there's interpolation for small movements. Certainly just the end states (a sad face, a happy face, a neutral face) would be enough and the rest would just be timing (morph from neutral to sad over 2 seconds, morph from sad to surprised in half a second, etc.). Larger changes (like, yes, unfurling wings. I was thinking more like tails and finer control for species specific behavior, such as the typical cat's tail tip moving while slightly amused, annoyed, or intrigued) would be possible if interpolation between intermediate frames were possible, and as such would require a lot more frames (something on the order of 8-10 key frames for interpolation of wings opening for instance to avoid vertex mishaps and to smooth out the animation a bit). Allowing for more frames would also give more options to cycle through (like 4-8 frames for a tail wag, 2-3 more for tip swishing, another 4-6 to allow for a state that curls the tail around you in a sitting state, tails in raised states doing some of these, lowered states, etc.). If a texture could be 1024x1024, that'd allow for 256 key frames of animation, an excessive amount to be sure but it's just an example. 512x512 would allow for 64 frames, something I feel would be much more likely to be filled out by a complex shape like a wing. A tail might only have only 16 frames if interpolated between each state, while a face would only have 4-8 (assuming only expressions. Should you try creating mouth charts to approximate speech, that's easily another 12 frames.

If there is no tweening to be had however, a smooth transition would need a lot more frames, and you're a lot more likely to see 1024x1024 textures being cycled through. That's a prospect I would like to avoid, as we have enough huge textures in world as it is. That is, of course, assuming that there's going to be animation of ANY kind. -- Feynt Mistral 11:49, 30 April 2007 (PDT)

A problem with keeping multiple frames in a single texture is the edges. There will be bleeding along the edges that will result in undesired effects. The only solution I see to this is to sacrifice a few pixels along the boarder to act as a bleed buffer (and have it cropped off before using). -- Strife Onizuka 11:04, 30 April 2007 (PDT)

Ah yes... The white ring effect I suffered with some tail textures... -.-;

I don't think that bleeding would happen with animated meshes. Bleeding happens with animated textures because the viewer loads the whole texture into OpenGL memory and manipulates a texture transform to paint part of it onto a prim face. But for sculpted prims I think that each frame would be logically or actually extracted from the whole mesh texture and that adjacent frames would explicitly be ignored. BamBam Sachertorte 21:00, 03 May 2007 (PDT)

I idly wonder if LL would consider a lossless format like PNGs at times like that, something that doesn't anti-alias pixels unwantedly, especially around the edges of the texture. There are plenty of tutorials out there on how to make a properly tiled texture, we don't need help from SL blurring the opposite edges of our pictures together. -- Feynt Mistral 11:54, 30 April 2007 (PDT)

Now I think about it, the edge bleeding won't be a problem because that comes from the rendering. But it's not so much the edges of the image that are the problem, but the edges of the frames. If this sort of framing is to be done, when the images are resized for LOD, the frames need to be resized individual and not the entire image all at once (or bleeding will occur). -- Strife Onizuka 12:06, 30 April 2007 (PDT)

Actually I rescind my "assuming that there's going to be animation of ANY kind" remark, it's been said that there will be animation. But whether a stream (which WOULD be nice, it would solve a lot of these problems) is going to be the only method or allowing for our present texture animation model to be incorporated as well is uncertain. If so, then yes these edge bleeding issues will be a problem. If not and they'll just be streamed only at some point in the future, then that eliminates the blur issue, texture size issues for frames of animation, and probably eliminates the need for interpolation (though being the generous sort and presenting interpolation if we want it between streamed frames would be heartily welcomed!). If streams are going to be the only method though, I agree with Argent's remarks in the LSL Functionality section about it being a long time coming before SL will be able to accept dozens and dozens of streamed prims at once without dying horribly. If Mono can ever get implemented, the scripting engine can have some kind of control over the texture map for the prim. That'd remove the need for streamed content, but would still allow for dynamic prim shapes. -- Feynt Mistral 12:44, 30 April 2007 (PDT)

i don't think i agree with all this pessimism regarding streams - we're talking about an extremely low-res animation with a small amount of frame data - which will be loaded once and played in a loop. as an exercise, i have 30 such of these running in quicktime windows on my desktop (as we speak.) these things are about the data size of an animating GIF...

Yes, now think of 30 of them running with SL active. Or better still, imagine 20 per avatar (just to be safe, because we know people will make something animated out of these for nearly every attachment point). With a dozen avatars in a sim, their load alone will be rather harsh on a client. Now throw in any objects in world that might be animated (rippling water in a pond or fountain for instance, or newer and more vibrant waterfalls. Or expertly crafted trees that sway slightly). Not to mention this streaming will be coming from outside of SL, from people with a wide range of upload speeds (my friend for instance has a 500kb download rate, but only a 20kb upload rate). Couple that with SL's need for high speed internet, and I'm not so sure streaming is an ideal situation on a grand scale. Allowing for multiple methods (especially in game scripting, because unless you're doing a playback of a rendered scene from a program like Blender, a custom program will be driving the sculpted texture stream) would ease the strain considerably. -- Feynt Mistral 16:48, 5 May 2007 (PDT)

Feynt - you're aware that the current anim texture mechanism is vastly less efficient than a stream, right? --Qarl Linden 18:02, 5 May 2007 (PDT)

I know that memory wise it's less efficient. Who'd want to use a 1024 x 1024 texture to animate a limited number of frames when a 64x64 stream takes up much less space for a potentially infinite amount of frames? But my concern is that unless there's a mechanism to allow this streaming from a stable source, SL won't be able to support the update speed needed and prims will go wonky when there's 100+ convulsing and writhing about in a sim. If it's handled by SL, this would increase the data being sent by SL and we'll have more contributing to latency issues. If it's handled by the users who want to stream this stuff, there's issues with what happens when they turn off their computer (if they stream sculpted textures from their computer) and can their connection support a dozen streams on top of all else they want to do? The option exists to have sculpted texture streams come in from a 3rd party source, but not everyone has access to that sort of a service for free (I think I might) and for everyone else that means paying some kind of monthly fee for hosting, which limits who can use these animated sculpted prims.

All I know for certain about the current texture animation system is it's in place, it works for furry heads to blink eyes pretty well, and it supports a number of interesting animation styles besides simply skipping from frame to frame. As an interim solution to animation it could be allowed with the provision that, "this is not the way it's suppose to be, expect this functionality to disappear shortly." But I'm not so much for this because as mentioned elsewhere in this ever growing page, the anti-aliasing from the JPEG2000 compression would blur together edges of frames causing unwanted changes to animated models. And on top of that we'd have more large textures to download, increasing rez time (especially rez time for objects).

Ideally I would prefer to see dynamic textures created by script, rather than by external stream. This would potentially be even better if done client side, as it would eliminate the need for SL to stream these textures too. It'd be like writing a custom shader for a prim, except instead of generating shadow maps it creates sculpt maps. Argent proposed some ideas for functions which make a lot of sense in this regard, but he suggests it for drawing on the face of a standard prim, rather than creating a sculpt map. It COULD be used for that purpose as well though. Alternatively (and easier for aspiring 3d programmers) the script could flat out assign the vertices to points in space through code. Assuming a local positioning system, with the center of the prim as 0, vertices could be assigned anywhere from -5 to +5 in any axis. If this functionality were added along with Mono, it would allow languages with multidimensional arrays to support assigning values to a [32][32] array of vectors. This something that you'd be able to accomplish if/when the SL client gets an editor to allow molding these prims. A client side approach does allow the prims to desync, however we already have this arrangement with particles, llTargetOmega rotations, and flexiprims and no one seems to care as long as they see roughly the same thing at roughly the same time. -- Feynt Mistral 13:32, 6 May 2007 (PDT)

whew - few ideas here - kinda tempted to reply inline, but that might be more confusing for those following along... basically don't much like the wiki-discussion format. :)

1) current animation system vs. quicktime (etc) animation system. you worry about latency/bandwidth from SL's servers for the stream option - but then you suggest that the current animation system is fine. i don't understand - it's exactly the same transition protocol - yet your suggestion has roughly 10x the data... so... i don't get it.

2) programmable shader options - YES. yes yes yes. absolutely, positively yes. sorry i haven't talked about that earlier... the astute have noticed that this geometry can easily be dynamically created on the GPU. this option is harder in that we need to provide a larger system to support it - but yes. positively a direction we want to head. --Qarl Linden 14:46, 6 May 2007 (PDT)

Sorry, I guess I wasn't too clear. I'm discussing streaming content versus the current texture animation system which loads a single texture. In the case of furry heads a 1024x1024 texture is divided into four 512x512 frames which are then cycled through. The image tiling rate is reduced accordingly and the image offset is changed to show the appropriate frame of the animation. For all intents and purposes, 4 frames (played forward and then backward) will account for all the important frames of a blink and looks smooth enough. Unless my client does something unexpected and caches the entire texture when it shouldn't. Because it does, I see all frames of the animation rez at the same clarity all at once as the blinking occurs. llSetTextureAnim is the function I speak of. It also allows for a smooth scrolling of the texture, or spinning of the texture, which in either case would allow for some really neato effects if you think about it!
Awesomeness incarnate. >3 Will this mean a separate language like GLSL or HLSL will be required? Will this be for actual shaders, or am I misinterpreting your point 2 when you mean something shader LIKE will be put together for dynamic texturing?

Also, OGRE3D has a lot of sample programs with it that demonstrate what it can do, chief amongst them in this case is dynamic texturing, might be worth a look. -- Feynt Mistral 17:23, 6 May 2007 (PDT)

Flexible

There are a few ways of doing flexible (the interface i mean).

The simplest would be to have a smooth movement from one side of the sculpt texture to the other. But that increases the complexity of making the sculpt prim and would look strange for highly complex shapes.
The next way that came to mind would be to add a fourth channel to the image that was the amount of flexibility that part should experience.
The last way is conceptually the simplest and would probably be the way you would generate the map used in the previous suggestion. Provide the user access to two vectors, a position and direction vector. Anything behind the point described by the position and direction would be static.
1. You could add a plane anchored at the point that would be perpendicular to the direction, the distance above the plane would be the amount of flexibility.
2. Or you could just do the distance from the point to that part of the mesh.
- A zero direction vector would mean the entire object was to be flexible.
- A quaternion could be used instead of the direction vector (a zero magnitude quaternion could fill the same roll as a zero vector).

I think the best way would be to use the second method and release a tool that generated the distance map based on the third method (and then added it to the mesh). The advantage of having a prebaked distance map would be to remove the need for the client to do that calculation (the amount of time required to do the extra image decoding might negate this). -- Strife Onizuka 08:04, 29 April 2007 (PDT)

I think the second idea of the fourth channel being a "flexichannel" would be the best idea. It would make the modeling of hair (or tendrils, or what have you) much easier. Since a 64x64 image would be mapped onto a 32x32 grid, this gives lots of room for subtle gradients in flexibility, with the base of the stalk being "coloured" as non-flexible. Reading Strife's remarks, I'm wondering if this is what he was getting at too. >) -- Feynt Mistral 12:31, 29 April 2007 (PDT)

You nailed it. 0 would be static base, 255 would be the end of the flex. By manipulating the map you could have some areas of the mesh appear less flexible then others. The problem I'm having is how you would program this, if you aren't careful you end up needing IK, the flex-channel would technically allow for things like...

Rope with ends tied off that sways in the breeze.
Circus tent: points on the mesh are marked static while the rest is made flexible.

I really don't think LL wants to be adding that to SL at this time, the amount of math isn't pretty (but it would be cool). -- Strife Onizuka 12:46, 29 April 2007 (PDT)

That WOULD be cool, but yes IK would be a tad much, not to mention computationally expensive. Working from what Qarl mentioned of the current status of flexiprims, being a 1 dimensional "string" allowing flexibility along the length of the prim, it would seem like each vertex would be an anchor point for the others around it, with a string in between it's immediate neighbours. This could allow bending in certain directions, but less (or none) in others, as some strings would remain rigid and would essentially push against the vertex should it try to bend the wrong way. This way seems a lot less computationally expensive, basically using the flexichannel as a sort of topographic map that the vertex would be moving across. It would have a natural tendency to bend towards the more flexible areas, kind of like a ball rolling down a hill. -- Feynt Mistral 13:50, 29 April 2007 (PDT)

you all are very correct. flexi's currently take a lot of cpu power (all that flexi hair is a killer) so we'll be VERY careful about making flexi sculpties. which means it'll take longer... don't expect flexi in rev2. :( --Qarl Linden 15:30, 29 April 2007 (PDT)

As long as we get some way to control the way a prim bends based on code at the least, I don't think many people will mind it. We can implement our own "flutter in the breeze" routines if we're allowed to mold prims by code. Although I'm wary about the strain it'd put on the engine, you could also hook up a weighting system to various vertices and let the physics engine figure out how it should all work. Obviously not something for the current implementation of Havok though (one head of hair would crash a sim for sure).

Honestly I can't see a better way than what we've discussed above at the moment. Guess I need to take a couple weeks off the question to come at it from a new angle. -- Feynt Mistral 16:26, 29 April 2007 (PDT)

I just remembered something which MIGHT be of use. It's very abstract to the flexiprim idea, but there's an article on Gamasutra about an honors thesis for realtime rendering of fur. I've managed to hook my engines teacher on this at school, and we plan on working together on it for a tech demo by the end of my term, improving the ideas stated within. The basic rundown of the important part though is that the code within the thesis demonstrates a way to render pretty realistic thick fur which responds to a wind force. Again, it's abstract, but the system generates dots on a variety of layers stacked above the object, and these dots are generated in the right order to appear to be fur blowing in the wind. This approach could be taken for generating a line for a flexiprim to move along. Or maybe not, just a thought.

Oh yes, you need an account with Gamasutra to see the page, but it's a good idea anyways as it has hundreds of articles which would help out. It's free too. >) -- Feynt Mistral 17:32, 6 May 2007 (PDT)

non-sculpted linkset to single sculpted prim

The benefit of sculpted prims is that they will allow new shapes, but also new and current shapes with less prims.

Following this idea, and excluding the fact that it would be easier to recreate from scratch, I thought that it would be interesting/handy to be able to convert a linkset of non-sculpted prims into one or more sculpted prims.

This could be made in-world, maybe without the need of the sculpt editor.

Simil - you're spoiling the surprise for rev2. :) --Qarl Linden 13:32, 29 April 2007 (PDT)

Or off-world, in the 3D softwares. In this last case, linksets would need to be exported : I have completed this step by creating a tool that exports (and imports) linksets in 3 (text) formats. The second step has aslo been completed with the Prim.Blender, SLPrims and SLmodel plugins. The third and final step is once you have imported the linksets in the 3D softwares using the above plugins, to convert them into a model that is able to be exported as a sculpt texture. The question then is to know if this conversion can be done and automated and if it gives a good enough result. --Simil Miles 12:34, 29 April 2007 (PDT)

Ooo, Qarl, does that mean a possible CSG union ability will be added? >D It would cut down on unnecessary polygons if they were all joined into one mesh. -- Feynt Mistral 13:39, 29 April 2007 (PDT)

Interesting. I wouldn't expect converted linksets to behave like a CSG though. The grid seems relatively low-resolution; a sphere and a square converted are probably going to look pretty soft and blobby. Get ready for a shift in the worlds design style. -- Csven Concord 15:10, 29 Apr 2007 (PDT)

Csven - yes, exactly. good for organic shapes... hence the name "sculpted". :) --Qarl Linden 15:20, 29 April 2007 (PDT)

Hmm so sculpted prims would be appear to be much more powerful than expected, since they wouldn't only rely on sculpt texture (created in 3D softwares) but could also be created "live", by direct manipulation - terrific, this is the real news.--Simil Miles 16:26, 29 April 2007 (PDT)

A friend in Serenity Woods made an interesting point a few days ago regarding this conversion. What happens to scripted objects which rely on a certain link number, or that rely on separate child prims? What about objects which change child prims from other prims (llSetLinkTexture for instance)? I wholly agree that this sort of thing SHOULD be made possible, having responsible sim owners converting 200-400 prim buildings into 30-50 sculpted prim buildings would be a real savings overall. However it should be up to the user which objects get this treatment because it may break some functionality otherwise. -- Feynt Mistral 17:08, 6 May 2007 (PDT)

Moving, compression

Ok, a few general questions:

1) How will the arrangement of pixels in the texture affect the result? If I want a cube, for example, so I have pixels for <0,0,0> <0,0,1> <0,1,0> <0,1,1> <1,0,0> <1,0,1> <1,1,0> and <1,1,1>, can I just put them in an 8x1 texture or what dimensions does it have to be? How will it affect texturing of the resulting prim?

2) How will the resulting object be scaled? Presumably the coordinates read from the texture are read based on unit values, and then scaled according to the scale of the object in the world?

3) How will JPEG2000 compression affect these textures? Will the lossiness when the textures are uploaded result in points on the prims shifting around slightly?

Yumi Murakami

Thats not quite how Sculpt Textures work. The description of the texture to make a cube would be much more complex. They aren't easy to to texture as the UV mapping will be specific to each one.
From what I can tell in R1 a full size mesh is 1.5 times larger then the size.
~~You would only get lossy compression if the image type you uploaded was a JPEG. Otherwise you would get lossless compression.~~

-- Strife Onizuka 13:12, 29 April 2007 (PDT)

Strife - not true. all of SL's textures have lossy jpeg2000 compression - regardless of their original file type. the fact that you've never noticed means it works well. :) --Qarl Linden 15:23, 29 April 2007 (PDT)

*digs through the source* My bad. I'm sure thats how things were done in the past. -- Strife Onizuka 16:37, 29 April 2007 (PDT)

In general, of course, it's bad compress twice, especialy if both methoods are lossy, cause that can make any compression artifacts worse. The only time I'd think about using JPGs for SL upload would be if I was doing a lazy grab some picture off the web type of thing but all my textures are tweaked for image quality and exported as TGA which of course is lossless. (Why compress at all instead of uploating BMP? Upload time.)

On point 3 that's what kind of confuses me. My understanding is that when you upload a texture to SL it is JPEG2000 compressed by SL itself, no matter what format you uploaded it in, and that when you upload a texture to SL it has no idea what you are going to use it for yet. So hasn't the compression already happened by the time you have the texture in your inventory, before you make your prim and set it to sculpted then drop the texture on it? Or is there some way of telling SL "this will be a sculpted prim texture, please don't compress it?" And is there some way of stopping people doing that for textures that are not to be used on sculpted prims? Yumi Murakami

Yumi - let's see how this works, first, before we get too excited. but to answer your question - we could easily reduce compression on all small (64x64) textures without causing any trouble. --Qarl Linden 15:25, 29 April 2007 (PDT)

JPEG and JPEG2000 are different. JPEG2000 has (nearly) no artifacts being used in their standard of compression. However, when they do appear by compressing it even more, they can be seen as smoothing rather than squares or mosquito noise that you'd see in normal JPEG format. The details wouldn't lose or corrupted as much, more smoother actually. --Vincent Nacon 13:57, 29 April 2007 (PDT)

When will this be released to the main grid?

On the article page for this entry, the FAQ mentions that this feature will be released into the preview grid (beta grid or first look grid(?)) sometime next week... But, when will this be released to the main grid and made available on the standard viewer? (Ina Centaur 16:53, 29 April 2007 (PDT))

Considering LL's track record somewhere between 3 months and 3 years. I know it would be nice to have a calendar date, so you can decide if you will start a big project with the old prims but it isn't even in preview yet. They don't know what bugs we will find in it. The bugs we find may have huge implications or expose other bugs, it's too early to set a more precise timeline. On a side note, the last time LL announced a timeline was for Havok 2, you know how well they stuck to that. -- Strife Onizuka 17:10, 29 April 2007 (PDT)

Ina - i wouldn't take Strife's negativity too seriously - the code is working well and the concepts are well explored. if the sculpties aren't on the main grid with two months, i'd be SERIOUSLY surprised. i expect much sooner than that. --Qarl Linden 21:26, 29 April 2007 (PDT)

We don't blame you Qarl, we blame the track records. ^.^;

We're still waiting on a Havok upgrade after many years with no word on how that's going. I had to coerce a visitor from Havok to my school in Toronto to divulge a progress report (a simple "it's going well, some problems have arisen but we're on it"). Likewise we're eagerly awaiting Mono, but there's been scarcely a whisper about that for months despite requests for updates. We want to believe though. -- Feynt Mistral 21:39, 29 April 2007 (PDT)

Feynt - fair enough, fair enough. hopefully we can start fixing that record. :) --Qarl Linden 07:54, 30 April 2007 (PDT)

Do you think you can put forth the idea that monthly or quarterly updates on project progress across the company would be a great benefit to public relations? I know I'd feel better if I knew what was taking Mono so long. I wants my Python. >3 -- Feynt Mistral 12:47, 30 April 2007 (PDT)

The recent open letter furvor has me just a bit worried...Yes the bugginess is nasty right now but it's been way too long since we've had anything new of signifigance for builders/creators (the last was 1.9.1, flexi prims and hardware lights). I can't say that resident "fix bugs first!" cries have been the cause of projects dying before, but they've likely contributed. I know Cube is a good dev (knew him pre-Linden days) and I'm getting to like you, Qarl, and I really hope you guys keep pushing this forward. Elle Pollack 10:47, 1 May 2007 (PDT)

One of my big concerns with the "fix bugs first" call has been that doing so would take years and in the mean time LL would loose developers to burning out or loosing interest and going elsewhere. If LL is going to devote itself to fixing bugs then it needs to transition into that and not spring it all at once on the developer pool. -- Strife Onizuka 11:36, 1 May 2007 (PDT)

Agreed. Without innovations SL will seem to have stagnated and then you'll hear people complaining that SL is "old" because nothing new has happened in weeks/months. It's a lose/lose situation, but as my teacher says "if you try to make everyone happy, you usually end up making them all mad instead." Ongoing projects like SL, or any MMO for that matter (or MU*, as I've seen this sort of thing happen before on them as well), will have to constantly fix bugs as time wears on. There's no ifs, ands, or buts about it. Concurrent user numbers increase, requirements grow, back ends need replacing. Any change will cause bugs. With this in mind, I think the current idea of innovating and fixing bugs on the side is a better plan than just focusing on bug fixes.

Besides, with the source gone public, if you think LL isn't fixing bugs fast enough YOU can fix them instead. -- Feynt Mistral 15:15, 1 May 2007 (PDT)

Trying to clarify how this works..

Discussion moved to Sculpted_Prims:Clarification_Page as part of the ICFTSA movement by Feynt Mistral 07/05/07

Technical explanation

Sculpted Prim Explanation

More impressive visual example?

SL Picture shows that the apple dent can easily be done with existing torus prims. Can someone show an example of something that can't currently be done with regular prims --- such as the folds on the cloth of a Jedi hood?

What about the 1-prim bananas? --Deanna Trollop 02:37, 1 May 2007 (PDT)

Bananas, or the reason why sculpted prims were created :D --Simil Miles 07:27, 1 May 2007 (PDT)

You mean like the plate the fruit is sitting on? -- Strife Onizuka 10:31, 1 May 2007 (PDT)

there a picture of Patrick Star floating around the blogs - he shows a very NON-prim example of what can be done. (don't want to use that pic in any official capacity - trademarks and whatnot.) --Qarl Linden 11:12, 1 May 2007 (PDT)

I wouldn't want to use that picture either, but that'd be because I don't like Spongebob. >.>;

Don't worry though, release the new client and we'll have plenty of new pictures to put up in its place. -- Feynt Mistral 15:21, 1 May 2007 (PDT)

Nevertheless, I'd really like to see sculpted prims being used for something like the jedi hood here. Link to Patrick Star (as manifested via sculpted prims) please? (Ina Centaur 16:33, 1 May 2007 (PDT))

Using Sculpties for a hood wouldn't be very satisfactory, you wouldn't get any movement in the fabric. -- Strife Onizuka 17:44, 1 May 2007 (PDT)

Ah, but you can. LSL can detect when an object changes location, and when the location is changed, script can animate the scripted prim texture to make it appear like the cloth has moved. But, anyway, seeing even a static implementation of the hood picture I linked above would be great and impressive too... gah, I've always wanted to wear a decent sith-monk hood on SL... (Ina Centaur 19:30, 1 May 2007 (PDT))

At the moment, animation consists of constantly setting the sculpted prim's 64x64 texture to a new one. That means having all the textures in the prim, and dealing with "not fully rezzed" prim states, and it might not rez fully before your script wants to change to another "frame" of the animation. If Qarl adds our regular texture animation in, so we can have separate frames in a... say.... 256x64 texture, or if we can get streamed textures going (which he's admitted won't be happening in this revision), that'll be a better alternative. -- Feynt Mistral 09:47, 2 May 2007 (PDT)

Sure you can detect the objects location/rotation but it's not meaningful on an AV. There is no way to detect when the head is tilted up, down or to the sides. It makes the rotation totally useless for this. -- Strife Onizuka 13:06, 2 May 2007 (PDT)

I think you could fake it a little if you made a hood in two parts, one to be attached to the head and one to the neck/spine, so that they move more properly with the avatar. It would look at least as good as a last-gen videogame model if you get the alignment right. When the ability to animate the texture comes along you could also script it to flutter when the avatar state is walking/flying. Elle Pollack 10:54, 4 May 2007 (PDT)

Very hacky previewers

Discussion moved to Sculpted_Prims:Very_Hacky_Previewers as part of the ICFTSA movement by Feynt Mistral 07/05/07

Sculpted prims using Paint Shop Pro

I might have found a way to create simple prims using paint shop pro. It doesn’t create complex shapes but with a little bit of understanding you can create embossed planes. It consist in creating a plane by using a horizontal gradient red texture going from black to red and back to black, Red Texture and using a vertical blue texture going from blue to black Blue Texture. Once the plane is created in xy you can separate the channels so you have the red channel and the blue channel, you edit in the green channel and draw on it to twist the plane. This might get tricky, the left half of the green channel is the front section, the right side is the back section, so if you create a low contrast image of what you want and paste it on both sides of the channel Ripled Green Example. Once your satisfied with your picture, you combine the channels (programs like Paint shop pro and photo shop have this kind of abilities) result. Save it upload it enjoy ^^ Rippled Prim --Pamagester Darracq 08:28, 5 May 2007 (PDT)

What sort of blending did you use on the layers? (are they seperate layers? Or did you work right in the red and blue channels?) Elle Pollack 18:04, 8 May 2007 (PDT)

Getting crowded here! Time to branch off?

It's getting harder to follow half a dozen discussions on this page, so perhaps time to branch off certian things to their own pages. Sculpted Prims: 3d Software Guide for starters. Sculpted Prim Explanation can be fleshed out more and I might suggest renaming it Sculpted Prims: Technical Guide. I can start working on the software guide later. Elle Pollack 10:02, 5 May 2007 (PDT)

agreed - sounds like a good plan. perhaps move the FAQ to a page named "FAQ" and the main page should route appropriately? --Qarl Linden 08:16, 7 May 2007 (PDT)

Or make the FAQ page and the main page can contain the basic explaination and links to the related articles. A mini-portal, basicly. Elle Pollack 11:34, 7 May 2007 (PDT)

To my mind, Sculpted Prim Explanation and the Glossary at Sculpted Prims Creators Guide could be merged and renamed into Sculpted Prims: Technical Guide as suggested by Elle or perhaps into something less abstract like Sculpted Prims: Under the Hood? The questions and answers inside the Glossary could be merged into the suggested FAQ sub-page, along with Qarl's original Questions and Answers on this page. And all pages should probably link to each other under a "See also" heading in order to avoid duplication / wasted efforts. Unless there's objections against this, I'd be happy to give that a go.
Update: I've created a Sculpted Prims: FAQ page to consolidate the main FAQ with various bit and bobs around the other Sculpted Prims pages (and yes, talk pages <grins>). Please have a look — if everyone is happy with it, we could go ahead and remove the FAQ from the Sculpted Prims page and turn it into a mini-portal. Also, I have added a [[Category:Sculpted Prims]] tag to some of the existing pages so that we can merge where appropriate and avoid duplicating efforts. For example, I do think Sculpted_Prims_Textures and Sharing_sculpt_maps_and_textures should be merged. Yuu Nakamichi 13:02, 8 May 2007 (PDT)

The glossary is meant to contain not just stuff relating directly to sculpted prims but a lot of general 3d modeling lingo, like verticies, viewport, unwrap, NURBS, etc. A lot of these things are encountered on SL on a daily basis but people don't know the terms for them and they're terms people are going to start running into now, i.e, people know about the avatar templates but not the fact that they're the end result of an unwrapping process. Whereas, I see the technical guide as being specificly "how do sculpted prims work", so I don't think the two pages belong together. I do agree with most of the other things you're saying though. Elle Pollack 17:27, 8 May 2007 (PDT)

Another subject that probably warrants its own page is editing sculpt textures in paint programs. So here goes the link: Sculpt Textures in Paint Programs

Also, Feynt? I appreciate you're trying to help with the clutter too but the way you're going about it seems a little...arbitrary? Under-planned? The way I'm going about it is trying to figure out what topics being discussed on here ought to have a whole article dedicated to them, writing the article (or at least editing it neatly together from what others have said), then moving stuff between talk pages. Elle Pollack 11:48, 7 May 2007 (PDT)

I'm actually copying entire sections out to a page titled "Sculpted Prims:<that heading name>". From there, I was thinking sub links could be made to individual discussions, or it could be left the way it was (which is, at present, kind of random in some sections). -- Feynt Mistral 22:28, 7 May 2007 (PDT)

Part of what I'm trying to say is that discussions should be moved to other talk pages, not article pages. And you can only have an article page if you have an article to go with it. From there they can be resorted and cleaned up like I did for the 3d software threads today. But a wiki isn't like a bullitin board or forum where every discussion gets its own page.

Wikipedia also manages clutter by archiving old Talk Page entries, but we're barely two weeks in, it's too soon to be thinking about that. Elle Pollack 10:37, 8 May 2007 (PDT)

thanks

hey everyone. i just wanted to take a moment and thank all of you for this incredible outpouring of collaboration/community development. it's been fantastic to watch.

so THANK YOU. and i hope you've had a nice weekend. --Qarl Linden 14:50, 6 May 2007 (PDT)

Ditto, and thank YOU for the back and forth discussion. Honestly, I think plenty of other projects could use this kind of interactivity. Now go outside and get a beer, no more coding for you today. >D -- Feynt Mistral 17:03, 6 May 2007 (PDT)

After Beta Testing Questions

Discussion moved to Sculpted_Prims_Beta_Discussion as part of the ICFTSA movement by Feynt Mistral on 07/05/07

Sculpted Prims and...Poser?!?!?

This is just too sweet. Sculpted Avatar Face. Elle Pollack 20:50, 7 May 2007 (PDT)