Difference between revisions of "Sculpted Prims:Clarification Page"

From Second Life Wiki
Jump to navigation Jump to search
m
m
 
(8 intermediate revisions by 3 users not shown)
Line 19: Line 19:
*50% Grey (127,127,127) -- < 0.0, 0.0, 0.0 >
*50% Grey (127,127,127) -- < 0.0, 0.0, 0.0 >


: Clarification request: The above statements imply that 0v = -0.5m, 255v = 0.5m, and 127v = 0.0m, but this cannot be precisely true -- at least one of those figures must be off.  I'm writing some programs to generate shapes, and for the sake of making accurate calculations and rounding most appropriately the results, I'd like to know which of these figures is not quite correct.  Is 0.0m precisely equal to 127v, 127.5v, or 128v?  If not 127.5v, then in which direction can the distance either not quite reach 0.5m or go over 0.5m a tad?  --[[User:Gaius Goodliffe|Gaius Goodliffe]]
: Clarification request: The above statements imply that 0v = -0.5m, 255v = 0.5m, and 127v = 0.0m, but this cannot be precisely true -- at least one of those figures must be off.  I'm writing some programs to generate shapes, and for the sake of making accurate calculations and rounding most appropriately the results, I'd like to know which of these figures is not quite correct.  Is 0.0m precisely equal to 127v, 127.5v, or 128v?  If not 127.5v, then in one direction the distance either cannot quite reach 0.5m or can go over 0.5m a tad, which is it?  --[[User:Gaius Goodliffe|Gaius Goodliffe]]
:: Additional info: I experimented a bit and I think I have the answer.  It appears that 0v = -0.5m precisely, 128v = 0.0m precisely, and 255v = 0.496m approximately.  Either that, or JPEG compression is messing up the position of my positive Z pole.  Can someone confirm? If so, in the above chart, it should probably say (128,128,128) = <0.0,0.0,0.0> rather than as it currently reads. --[[User:Gaius Goodliffe|Gaius Goodliffe]]


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?)
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?)
Line 72: Line 73:
Funny thing is, the only thing that took me a little while to understand was why pixel order mattered at all - the obvious answer to my question being, to give it a sequence of connections so that it doesn't make wild mistakes in which vertex connects to which.--[[User:Al Sonic|Al Sonic]] 20:35, 30 April 2007 (PDT)
Funny thing is, the only thing that took me a little while to understand was why pixel order mattered at all - the obvious answer to my question being, to give it a sequence of connections so that it doesn't make wild mistakes in which vertex connects to which.--[[User:Al Sonic|Al Sonic]] 20:35, 30 April 2007 (PDT)


:[http://forums.secondlife.com/showthread.php?t=180494&page=2#post1491568 Here] is a forum post with attached example images , re: making a sculpt map for a cube.
:[http://forums-archive.secondlife.com/8/75/180494/1.html Here] is a forum post with attached example images , re: making a sculpt map for a cube.


:Oh, BTW, another question which popped into my skull recently...  when you say a 32x32 grid, is that 32 ''verts'' (31 squares in between), or 32 ''squares'' (33 verts)? --[[User:Deanna Trollop|Deanna Trollop]] 05:37, 2 May 2007 (PDT)
:Oh, BTW, another question which popped into my skull recently...  when you say a 32x32 grid, is that 32 ''verts'' (31 squares in between), or 32 ''squares'' (33 verts)? --[[User:Deanna Trollop|Deanna Trollop]] 05:37, 2 May 2007 (PDT)
Line 89: Line 90:


:Yes, reversed vertex order does render as "inside-out." I tried that with my sample cube map, by value-inverting the red channel, essentially mirroring the vert coordinates on the X axis without changing any of the vertex-to-poly assignments. --[[User:Deanna Trollop|Deanna Trollop]] 19:58, 5 May 2007 (PDT)
:Yes, reversed vertex order does render as "inside-out." I tried that with my sample cube map, by value-inverting the red channel, essentially mirroring the vert coordinates on the X axis without changing any of the vertex-to-poly assignments. --[[User:Deanna Trollop|Deanna Trollop]] 19:58, 5 May 2007 (PDT)
I understand most aspects of sculpted prims but there is one issue I have not been able to overcome. The issue relates to the positioning and scale of a sculpt that is exported multiple times with slight adjustments to produce frames in an animation. For instance, I have created a human appendage that has 4 positions. In the first position, the scale looks correct. The problem arises when sculpt texture 2,3 and 4 are applied; even though the 'prim' position and scale are identical, the sculpt is rendered using positioning relative to the sculpts center. What this means is that as the sculpt texture changes, the relative center and relative scale of the object does not correspond to the previous sculpt textures scale and position. In order for the sculpts to become the right scale, the actual prim must be repositioned and rescaled.
To give you a real example to work with I have taken the scales and position information for the 4 sculpts, all resized to the correct scale and repositioned so that the sculpts appear to originate at the same location. What I need help with is an equation or function that will allow me to gaurantee that these sculpts will become the right scale and in the right position when they change.
Sculpt 1 - (Scale = 0.579,0.550,0.550) (Position = 94.015,152.798,24.992)
Sculpt 2 - (Scale = 0.683,0.660,0.652) (Position = 94.080,153.220,25.066)
Sculpt 3 - (Scale = 0.956,0.856,0.909) (Position = 94.184,153.641,25.076)
Sculpt 4 - (Scale = 0.863,0.805,0.831) (Position = 94.159,154.065,25.162)
I have heard rumors about animating sculpts via Flash at some point in the future so I assume someone has found a solution to this issue. If so please share it with us, I am going mad trying to figure this out ; ) My goal is to allow the user to resize the appendage normally and have a script calculate the correct scales and positions for each subsequent sculpt.
Note - I only work in Maya 6.5, I'm not sure if my problems are directly related to this application or if all sculpted prims suffer from this issue. --[[User:Nulflux Negulesco|Nulflux Negulesco]] 23 June 2007
: What you are describing is the result of each individual sculpt map being produced from a separate bounding box, based on the individual geometric min and max values of each sculpted object.  This is something I'd taken into account in writing my exporter for MilkShape.  Originally I had considered giving an option to set the center of the bounding box to the absolute world origin, but now that I think about it, it would be better to have the option of calculating one overall bounding box from the min and max of multiple sculpts.
:Note, however, that what you are doing now, finding separate scale and positioning values for each "frame" of the animation, is a little more work, but provides the best quality sculpt.  Producing a sculpt map based on a bounding box which overshoots the geometric bounds of a sculpt degrades the quality, by not using the full 0-255 range possible. --[[User:Deanna Trollop|Deanna Trollop]] 09:23, 24 June 2007 (PDT)
:: Thanks for the reply Deanna, but I don't see how I can animate an organic shape without changing the bounding box in some way. For example, a sculpt of a human arm. It bends in 3 places, so if you start with the arm outstretched then bend the arm, you end up changing the bounding box of the sculpt. To complicate matters even further, by changing the bounding box you not only alter the scale of the object but also change the origin of the attaching point of the arm (in this case the shoulder). The 'little bit of work' that I  use to rescale and reposition the object is actually quite a lot of work if I am doing it on a regular basis for every frame of every sculpt animation that I create, especially since the scaling and positioning are entirely different for each set of sculpts.
:: Even with identical bounding boxes in Maya, I still have to alter the prim to properly scale and position the sculpt in SL. There has to be a cleaner way to do this. --[[User:Nulflux Negulesco|Nulflux Negulesco]] 25 June 2007


[[Category:Sculpted Prims]]
[[Category:Sculpted Prims]]

Latest revision as of 13:41, 9 April 2010

This discussion relates to Talk:Sculpted Prims

Moved by Feynt Mistral on 07/05/07


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 >
Clarification request: The above statements imply that 0v = -0.5m, 255v = 0.5m, and 127v = 0.0m, but this cannot be precisely true -- at least one of those figures must be off. I'm writing some programs to generate shapes, and for the sake of making accurate calculations and rounding most appropriately the results, I'd like to know which of these figures is not quite correct. Is 0.0m precisely equal to 127v, 127.5v, or 128v? If not 127.5v, then in one direction the distance either cannot quite reach 0.5m or can go over 0.5m a tad, which is it? --Gaius Goodliffe
Additional info: I experimented a bit and I think I have the answer. It appears that 0v = -0.5m precisely, 128v = 0.0m precisely, and 255v = 0.496m approximately. Either that, or JPEG compression is messing up the position of my positive Z pole. Can someone confirm? If so, in the above chart, it should probably say (128,128,128) = <0.0,0.0,0.0> rather than as it currently reads. --Gaius Goodliffe

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

Well, the concept of the minimal-pixel cube makes perfect sense to me; it seems it would involve a 4×2 pixel map, plus, to keep it from messing up the top and bottom sides, a row of repeated vertices on the top and bottom to make it 4×4, something like...

<.5,.5,1> <.5,.5,1> <.5,.5,1> <.5,.5,1> = light blue

<0,0,1> <0,1,1> <1,1,1> <1,0,1> = blue, cyan, white, magenta

<0,0,0> <0,1,0> <1,1,0> <1,0,0> = black, green, yellow, red

<.5,.5,0> <.5,.5,0> <.5,.5,0> <.5,.5,0> = dark yellow

It's only just a bit ago that I seem to have grasped how the whole idea functions, so do by all means correct me if I'm off at all. Funny thing is, the only thing that took me a little while to understand was why pixel order mattered at all - the obvious answer to my question being, to give it a sequence of connections so that it doesn't make wild mistakes in which vertex connects to which.--Al Sonic 20:35, 30 April 2007 (PDT)

Here is a forum post with attached example images , re: making a sculpt map for a cube.
Oh, BTW, another question which popped into my skull recently... when you say a 32x32 grid, is that 32 verts (31 squares in between), or 32 squares (33 verts)? --Deanna Trollop 05:37, 2 May 2007 (PDT)
First, @Deanna: Well in the Explanation, the green squares are pixels, and the red lines are the resulting sculpted shape. So we're talking about a grid of 32 pixel-verts across, and that this also means 32 'squares' (which are actually triangle-pairs) between them... horizontally at least. Vertically there are 31 'squares', plus a row of triangles above and below them, leading to the 'poles' of the prim. I'm left wanting a little clarification on just how it would determine the 'poles' of the figure, but they should turn out to each be an average of the row of vertices next to them.
This was one of the first things I checked out once Sculpties went live (once I realized it was the ultra-borked flexi prim implementation in the new beta which was causing frequent, unprovoked crashes... but I digress). It is 32 rows and columns of "squares", which leads me to believe that the latitudinal coordinates end up interpolated between sculpt map pixel rows, since there will be 33 rows of verts spread out over 2^n rows of pixels. --Deanna Trollop 19:58, 5 May 2007 (PDT)


This kinda leaves me thinking of sculpties as being like formless cylinders, just without a top and bottom texture (which is what makes it a "sphere" map instead... plus the physics engine thinks they really are just sphere prims). Not that they couldn't have implemented a top and bottom texture if they wanted... hmm....

What makes them "spherical" is more the fact that the top and bottom rows of verts are unified to points at the "poles". --Deanna Trollop 19:58, 5 May 2007 (PDT)


What really gets me thinking is, could I create an inverted sculptie by mapping my points around in the wrong direction? Counter-clockwise? Clockwise? Which way is it? Or would it insist on correcting the shape to keep the outsides out? I hope not; this sounds like the greatest opportunity ever to play with bending faces off in uncommon directions. --Al Sonic 18:18, 5 May 2007 (PDT)

Yes, reversed vertex order does render as "inside-out." I tried that with my sample cube map, by value-inverting the red channel, essentially mirroring the vert coordinates on the X axis without changing any of the vertex-to-poly assignments. --Deanna Trollop 19:58, 5 May 2007 (PDT)

I understand most aspects of sculpted prims but there is one issue I have not been able to overcome. The issue relates to the positioning and scale of a sculpt that is exported multiple times with slight adjustments to produce frames in an animation. For instance, I have created a human appendage that has 4 positions. In the first position, the scale looks correct. The problem arises when sculpt texture 2,3 and 4 are applied; even though the 'prim' position and scale are identical, the sculpt is rendered using positioning relative to the sculpts center. What this means is that as the sculpt texture changes, the relative center and relative scale of the object does not correspond to the previous sculpt textures scale and position. In order for the sculpts to become the right scale, the actual prim must be repositioned and rescaled.

To give you a real example to work with I have taken the scales and position information for the 4 sculpts, all resized to the correct scale and repositioned so that the sculpts appear to originate at the same location. What I need help with is an equation or function that will allow me to gaurantee that these sculpts will become the right scale and in the right position when they change.

Sculpt 1 - (Scale = 0.579,0.550,0.550) (Position = 94.015,152.798,24.992)

Sculpt 2 - (Scale = 0.683,0.660,0.652) (Position = 94.080,153.220,25.066)

Sculpt 3 - (Scale = 0.956,0.856,0.909) (Position = 94.184,153.641,25.076)

Sculpt 4 - (Scale = 0.863,0.805,0.831) (Position = 94.159,154.065,25.162)

I have heard rumors about animating sculpts via Flash at some point in the future so I assume someone has found a solution to this issue. If so please share it with us, I am going mad trying to figure this out ; ) My goal is to allow the user to resize the appendage normally and have a script calculate the correct scales and positions for each subsequent sculpt.

Note - I only work in Maya 6.5, I'm not sure if my problems are directly related to this application or if all sculpted prims suffer from this issue. --Nulflux Negulesco 23 June 2007

What you are describing is the result of each individual sculpt map being produced from a separate bounding box, based on the individual geometric min and max values of each sculpted object. This is something I'd taken into account in writing my exporter for MilkShape. Originally I had considered giving an option to set the center of the bounding box to the absolute world origin, but now that I think about it, it would be better to have the option of calculating one overall bounding box from the min and max of multiple sculpts.
Note, however, that what you are doing now, finding separate scale and positioning values for each "frame" of the animation, is a little more work, but provides the best quality sculpt. Producing a sculpt map based on a bounding box which overshoots the geometric bounds of a sculpt degrades the quality, by not using the full 0-255 range possible. --Deanna Trollop 09:23, 24 June 2007 (PDT)
Thanks for the reply Deanna, but I don't see how I can animate an organic shape without changing the bounding box in some way. For example, a sculpt of a human arm. It bends in 3 places, so if you start with the arm outstretched then bend the arm, you end up changing the bounding box of the sculpt. To complicate matters even further, by changing the bounding box you not only alter the scale of the object but also change the origin of the attaching point of the arm (in this case the shoulder). The 'little bit of work' that I use to rescale and reposition the object is actually quite a lot of work if I am doing it on a regular basis for every frame of every sculpt animation that I create, especially since the scaling and positioning are entirely different for each set of sculpts.
Even with identical bounding boxes in Maya, I still have to alter the prim to properly scale and position the sculpt in SL. There has to be a cleaner way to do this. --Nulflux Negulesco 25 June 2007