Talk:Sculpted prim

From Second Life Wiki
Jump to navigation Jump to search

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)

[1]
Woot ^_^ thx. -- Strife Onizuka 14:45, 27 April 2007 (PDT)
/me adds additional Woot! ;-P --AlisonW 15:42, 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)

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 .....

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)

Will the Maya exporter work with Maya Personal Learning Edition? [3] --Kamilion

haven't tried it - but i believe the personal edition puts gaudy maya watermarks on images - which would definitely cause sculpties grief... but this isn't a typical rendering, so perhaps not. worth an experiment. --Qarl Linden 09:58, 28 April 2007 (PDT)

Hi, I just tried it and and it does unfortunately watermark the resulting image with the free edition. (P.S. Even so, still, WOOOT!!! :)) --Logan Bauer

This is unlikely to happen because of SL's potential commercial applications, Buuuuut..... Epic Software apparently has a standing deal where their export plugin for Unreal Tourniment 2k3 mods works in Maya PLE without the normal restructions (this may be holdover from before Autodesk bought them). Might it be possible for Linden Lab to look into a similar deal? Elle Pollack 14:58, 28 April 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)

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)

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)

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 pase_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

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)

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)

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.

(Merging related questions under this header. Elle Pollack 13:14, 28 April 2007 (PDT))

I know of three perfectly free modellers that run on many platforms: Blender, Google's SketchUp, and the open source Wings3D which I use with X-Plane. It would help the "pennyless" content makers tremendously to have exporters for these.

- I'm not sure if Sketchup has the functionality required for this sort of thing. It can do plugins (Python, IIRC) , but it doesn't have much in the line of map rendering and export of non-native formats except maybe for .jpg renders is tied to having the paid "Pro" version. There might be importers for skp files into other programs. Might. Elle Pollack 12:05, 28 April 2007 (PDT)

In considering programs to offer export support for, is there any chance of offering support for Caligari Truespace [4]? It is priced much more in reach for the average users than 3d Studio Max/Maya, and is not as esoteric as Blender. Cristiano Midnight 21:12, 27 April 2007 (PDT)

- these exporters are really easy to create - basically if your program has a normal-map generator (most do) it's a simple mod to make a sculpt exporter. so i challenge YOU Cristiano to make the truespace exporter.  :) --Qarl Linden 09:43, 28 April 2007 (PDT)

-- if i understand the issue right, the main obstacle at the moment would be: the displacement map is "baked" into texture which is created based on UV map associated with low resolution prim. In case of SL sculpt prims, this low res UV map is "hard coded" property of the sculpt prim as it's rezzed in SL rather than anything user would create themselves, and so the displacement map generator has to be given this exact prim with this exact UV map to use it as baking reference or Bad Things(tm) happen. Is there any chance such reference "sculpt prim" with its UV map could be provided for download, perhaps in .obj format for easy use?

- Gonna post tech specs for that sort of thing any time soon? Won't help me much since I'm not a coder, but... Elle Pollack 13:14, 28 April 2007 (PDT)

- Eddy Stryker says he made an exporter for Blender.

-- Linkage?


i spoke with Eddy Stryker - he does indeed have a procedure for extracting sculpt textures from blender. currently it's a bit of manual labor - he's looking from someone who knows blender's scripting language so he won't have to learn it himself.  :) --Qarl Linden 13:03, 29 April 2007 (PDT)

- IIRC, I belive Blender uses Python for scripting. Eddy hangs out with enough programers that he ought to be able to find *someone* with that qualifation. :) (Jeffery Gomez is the reigning guru of Blender to/from SL projects, last I checked.) Elle Pollack 15:54, 29 April 2007 (PDT)

If NURBS are going to be the recommended methood of making SL objects...for about the price of a Photoshop suite ($995 for the full licence, $195 for students) there's Rhino 3D, which is made with NURBS in mind. I don't know much else about it at this point but it supports plugins and has a trial version (full functionality for 25 saves). http://www.rhino3d.com Elle Pollack 13:14, 28 April 2007 (PDT)

whoa, no need to buy rhino, I think its overkill, besides - you can't really texture anything in it. if I read correctly, this is more like maya, in which case we're talking patch models. there are lowcost to free patch modelling programs, like A:M, hamapatch, etc. rhino doesn't function like that really, it's a great program but it's not as good for organic modelling. but this is all under the hood stuff. I suspect a polygon model made to approximate the control points and uvspace of the prim will be plenty good enough to work with - and you can sculpt it to your hearts content in a variety of low-cost programs from blender (free) to silo, hexagon, up to programs like zbrush (which would be my preferred method, as I can up and downsample the resolution). I'm guessing based on the info provided about the texture, we're talking about a low poly model limited to 64 control points. --Hypatia Callisto 14:23, 29 April 2007 (PDT)

One of the programmers responsible for Rhino is working on a tool called Moment of Inspiration. Functional beta is available online. Not sure how long it'll be useful, but it does export to .3ds, .obj, .iges, .stl, and OpenNURBs (aka Rhino3D format).
In addition, there are other NURBs-capable modelers available. Art of Illusion is an open source, Java-based hybrid modeler iirc. Ayam is another NURBs modeler that some people might prefer. -- Csven Concord 17:40, 28 Apr 2007 (PDT)

Why not provide (for example) a 3DS to texture converter instead of a conversion plugin? Most programs I've seen will save and load 3DS format, so this would be just the same as writing an exporter plugin. Yumi Murakami

- If someone were to go that route, they might be better off using OBJ format, which every polygon modeler worth it's salt can export, or MDL which is less common but the files can be read as plain text like BVH (Neverwinter Nights uses it and there are some existing tools to work with it); it's closer to being a "standard" format than 3DS. I like the idea, but for programers, a lot of existing 3d suites have the ability to render textures built in, which I think would make plugins easier to write initialy.

-- the reason it's better to write an exporter is for programs which can generate a normal map from displacement painting a low polygon mesh. Most of these programs let you subdivide the model to higher resolutions, letting you displacement paint with better detail, giving you a map that can better approximate nurbs-style patch curves, rather than the blocky nature of a polygon model. (OBJ and 3DS are polygon model formats) --Hypatia Callisto 16:20, 29 April 2007 (PDT)

While on the subject of export formats, does anyone know the prefered format to export NURBS objects in? (OBJ and 3DS are both polygon exports). Elle Pollack 12:16, 29 April 2007 (PDT)

to answer this question - Rhino's 3DM format is becoming a standard in that area. But my previous statement holds - no need for Rhino for sculpties. You need a modeller that can export a normal map. Probably best would be some kind of converter to deal with Zbrush's normal maps to turn them into sculptie format. Most programs which can import/export and use normal maps can deal with Zbrush-type maps. --Hypatia Callisto 03:15, 30 April 2007 (PDT)

one problem is that no one can agree on which program is the best, which format, etc, etc. ideally i'd like to see our vibrant community develop the import/export mechanisms - they're the ones who know exactly what the want/need. --Qarl Linden 13:09, 29 April 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)

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)


* 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)


: 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)

- 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 [5] 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)

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 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)

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)

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)

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

  1. 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.
  2. From what I can tell in R1 a full size mesh is 1.5 times larger then the size.
  3. 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)

Trying to clarify how this works..

For folks like me who aren't already playing with the alpha versions :)

If I understand right.. we start from a normal map, which is basically a texture that we wrap around a 3D shape to give our 3D application more information about how light hits it, so it can shade it based on that, and thus look better than it otherwise would without needing to add more vertices.

But now instead of encoding the normal vector, we are going to encode the position of each point? In what coordinate system? Relative to the object's origin (which is.. the centre?) or relative to where the point "would otherwise" have been had the map not been applied (assuming such a concept exists). How do we encode a negative value is a colour? What is the scaling?

yes - you are exactly correct. the coordinates are in "object space", relative to the center of the object. positions are translated, rotated, and scaled by the placement matrix (the prims position, rotation, and size parameters.) --Qarl Linden 07:49, 30 April 2007 (PDT)


To clarify, the 0-255 range of a given color channel value (R, G or B) is converted to the -0.5 - +0.5 range of a given axis (X, Y or Z, respectively), representing an offset from the position vector of the prim, which is then multiplied by the prim's overall Scale value for that axis. So, a few concrete examples, assuming a scale of <1,1,1>:

  • Color -- Coordinates in "prim space"
  • Red (255,0,0) -- < 0.5, -0.5, -0.5 >
  • Green (0,255,0) -- < -0.5, 0.5, -0.5 >
  • Blue (0,0,255) -- < -0.5, -0.5, 0.5 >
  • 50% Grey (127,127,127) -- < 0.0, 0.0, 0.0 >

If the scale of the prim were <2,1,1>, then of course you'd multiply the X components of the above vectors by 2. (Any corrections to this, Qarl?) --Deanna Trollop 08:04, 30 April 2007 (PDT)

Ok, I'm starting to see this now! So if I wanted to make a unit cube, then I need:

  • The top face: <-0.5,-0.5,0.5> to <0.5,0.5,0.5>, ie, a gradient of blue > white
  • The bottom face: <-0.5,-0.5,-0.5> to <0.5,0.5,-0.5) ie a gradient of black > yellow
  • The left face: <-0.5,-0.5,-0.5> to <-0.5,0.5,0.5> ie a gradient of black > cyan
  • The right face: <0.5,-0.5,-0.5> to <0.5,0.5,0.5) ie a gradient of red > white
  • The front face: <-0.5,-0.5,-0.5> to <0.5,-0.5,0.5> ie a gradient black > magenta
  • The back face: <-0.5,0.5,-0.5> to <0.5,0.5,0.5> ie a gradient green > white

And I can put these gradients anywhere I want in the texture, with the proviso that if I want to texture the prim, the texture mapping will correspond to the pixel locations in the sculpt texture, so I ought to put them somewhere sensible.

Is that right? I'll confess that I'm still not seeing why I can't make a cube with just 6 pixels - I have the idea that I can choose the level of detail for bits of a sculpted prim by how many pixels I assign them in the texture, but for a cube you only need 6 vertices and 12 triangles as long as you don't want to texture it surely.. Yumi Murakami

Edit.. I just looked at Eddy's explanation.. so I can't just put them anywhere I want, because the 4 neighbours of a pixel determine the other ones that it's linked to, but on the other hand there's no idea that the pixel that's above another in the sculpt texture has to be "above" it in the object, because there is shape to the object and thus no concept of aboveness in the object save that defined by the pixel colour values.

So for my minimum pixel cube the map would be something like:

Green, Yellow, UNUSED, UNUSED

Cyan, White, UNUSED UNUSED

Blue, Magenta, White, Cyan

Black, Red, Yellow, Green


So that the wrap around across the lower two horizontal lines creates the front, right, back and left faces, and the wrap around across the left-hand two vertical lines creates the front, top, back and bottom faces? How do you say that a given pixel isn't used, or can't you?


  • I wouldn't think you could define "unused" pixels/verts. They all get used. Think of it this way, you're just distorting a sphere. The polys which converge at the poles have to go somewhere. Logically, the top and bottom faces of your cube would consist of roughly 1/6 of the polys (each) in a radial pattern, and the other 4 sides would consist of the remaining polys in a grid pattern. Take the latitude and longitude lines of a globe. Distort the 45 N and S latitude lines into squares, making the top and bottom edges of the cube, connected at the corners by the 45 and 135 E and W latitude lines.
  • How would this look as a sculpture map? It gets a little complicated at the top and bottom edges, which must be vertical gradients to 50% on R and G (where the polys converge at <0,0,+/-0.5>), mixed with horizontal gradients. I tried doing exactly this "by hand" in PhotoShop the other day as a mental exercise, and quickly got confused. ;)

Technical explanation

Sculpted Prim Explanation

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Talk:Sculpted_prim&oldid=19294"