Talk:Sculpted Prims/Beta Discussion

This relates back to Talk:Sculpted Prims

Separated by Feynt Mistral on 07/05/07

After Beta Testing Questions

• Few times I've made some shapes in Blender and I get sphere. When zooming away for LOD change, I can barely see my original shape that I've created... Why am I getting a sphere at first level of LOD? It seem to happen whenever you are trying to make something complex but not as a "vertex vomit". Although, vertex vomit are easy to get, but they don't turn into sphere? What's the deal? --Vincent Nacon 19:52, 6 May 2007 (PDT)

• I believe I know why that is, but keep in mind this is theory on my part. As you get further and further from the prim, it halves the number of vertices and averages the colour gradients between vertex points to figure out what goes where and how the face inbetween should be drawn. While you may have a lot of vertex complexity in a small area (like a really defined face for instance) it's averaging away and becomes more and more sphere like. "vertex vomit" however is sufficiently different that even when averaged, it still appears all over the place.

As a suggestion to Qarl, do you think you could set it up in the LoD slider that maximum LoD shows full detail on all sculpted prims up to the 64m from the camera, and then the normal reduction per 16-32m afterwards? -- Feynt Mistral 21:31, 6 May 2007 (PDT)

yeah, on my list of fixes this week. --Qarl Linden 08:12, 7 May 2007 (PDT)

It doesn't explain why something that is a working complex design become a sphere... while any texture can become vertex vomit, which is more complex than a working complex design and not turn into a sphere. It's becoming insane for a designer like myself, trying to make an object that has a lot of 90* angle design. It just seem like a sad day for machine designer than organic designer. --Vincent Nacon 22:17, 6 May 2007 (PDT)

that sphere thing is likely a bug. sculpties become spheres when there isn't enough information in the texture to create a valid prim (for instance, if you apply a blank texture, all the points lock to the origin, and the prim disappears.) send me the texture and i'll take a look at it. --Qarl Linden 08:12, 7 May 2007 (PDT)

I had actually noticed that zooming in on some chamfered boxes in a sandbox caused them to revert to spheres when I got too close. This MIGHT have something to do with the the prim being drawn larger than the physics bounding shape. Everything else in the client may be thinking the actual shape is smaller, but the new sculpted prim code thinks it's larger, and when you penetrate past the skin of the prim it goes into this "no prim data, make it a sphere" mode. -- Feynt Mistral 09:01, 7 May 2007 (PDT)

Can anyone clarify why the image below: Doesn't produce a cube? The coloured area accounts for all of the needed faces, and grey areas move all the "unused" coordinates to the prim's origin where they should create triangles that are invisible inside the cube. The texture is 64x64 to prevent scaling problems. Yumi Murakami

You have 12 vertex data in there.... why? Cube only have 8 corners. Plus, that's not how the mapping works. You need to see the grid layout that Qarl showed at Sculpted Prim Explanation page. --Vincent Nacon 21:51, 7 May 2007 (PDT)

It seems to meet the requirements for the mapping shown on that page. The points where the colour blocks intersect should create the necessary triangles for the cube. The business where the top row and the bottom row are all linked to a single point, which is their average location, should be neutralised by the grey blocks there which send everything to <0,0,0>. And the above texture defines a UV map, ok, it's a strange UV map but it could still be one. What it seems is that the system does indeed produce two triangles per four pixel block, but that it also runs a set of other checks as well, and if those aren't satisfied, it returns a sphere. The question is exactly what are those checks? I suppose we'll know when the viewer source comes out... -- Yumi Murakami

Yumi, while I do get quite a sense of where you're trying to go with that, might I ask we simplify it down to this cube and see what it does? (I made it, so I can explain it too. Oh and by the way, this image is reversed to work with the new beta.) --Al Sonic 19:37, 14 May 2007 (PDT)

---

After Beta 1.16.0(1) May 15th Questions

---

As far I understand there a change been made to sculpted prim's mesh to tie with the texture (thus new texture requirement). The top and bottom row of pixel in a texture are ignored except one of each row pixels are assigned for polar point on both ends? Meaning there's 30 segments from top to bottom instead of 32. Would need to know which pixel on the top and bottom row are assigned as polar point for both ends.
(If this isn't true, then I may have discovered me a bug.) :/ --Vincent Nacon 09:18, 17 May 2007 (PDT)

This is due to a bug that is here since start of sculpting. It's not due to the update. I already identified it in code and have shown it to Qarl. The cause is that the first and last lines are indeed gone because the loop works incorrectly and so first and last line of vertices are replaced by poles. Should be fixed on next release. --Blakar Ogre 09:05, 19 May 2007 (PDT)

Ahhh, the source of my problems - to some extent. However, any chance of an explanation of how it should work? i.e. Where the poles should be (hopefully just in the centre of the top and bottom rows) and the topology of the linking? Also how this will affect UV mapping (will we need to add an extra row of faces at the top and bottom of the UV map ?) --Max Duesenburg 08:55, 20 May 2007 (PDT)

Currently poles are on top and bottom row on width/2. So for example a 32x32 texture will use pixel 17 (or 16 if you start counting from 0). Judging by how the code was intended to work for the bottom I think the goal is to keep them there. I have no idea on UV-mapping. That can only be truly tested once it is fixed. --Blakar Ogre 14:40, 20 May 2007 (PDT)

• After experimenting a bit with sculpted prims, it seems that the interpretation of the sculpted prim used by the physics engine can be incredibly inappropriate - it is often far too large in many cases. This makes it difficult to use in vehicles, which cannot be phantom in any way. How about changing it so that sculpted prims are approximated by the physics engine with a very small box, or are implicitly phantom? We can always add a prim or two to better approximate an object's shape to the physics engine, but we can't subtract a badly approximated bounding box's shape. --Francis Chung May 20 2007

When will sculpted prims be released to the main grid? I seem to recall an announced roll out date of 5/23.

JPEG 2000 compression artifacts

Qarl, I see that you tried to decrease the problems caused by compression in release 16.0.0.1. But it doesn't seem to have had too big an effect. JPEG 2000 has a number of wavelet transform options, one of which is invertible (the 5/3 transform in reversible mode) and can give essentially lossless compression. Have you tried using that for small textures? It sure would be nice to not to have doubled-up vertices "explode" at high LOD. --Omei Turnbull 10:09, 17 May 2007 (PDT)

Compression artifacts are a serious issue for the kinds of things I'd like to build. My primary concern is that the artifacts make it difficult to build large organic structures out of several component prims. Think treehouses or terrain, things that are bigger than 10m in size and thus require multiple prims. The issue has to do with the seams between prims. Compression causes edges to be uneven and/or rounded. In many cases that's fine if you're building a single organic prim, but when you try to put them together, it creates ugly non-organic seams. The lighting system makes this especially apparent, since the surface normals don't transition smoothly across the seam. I can make the prims fullbright and that helps, but LL did an awesome job with the lighting system. I don't want to have to disable it. And in the current version, it really does make a huge difference what the resolution of the bitmap is. If I use 256x256 texture, the result is *much* better than a 64x64 texture. I don't think this problem will be solved until a 64x64 texture yields a result that is at least as good as a 256x256 texture.--Shack Dougall 09:24, 18 May 2007 (PDT)

• I wanted to talk about non-organic shapes. I've been trying many ways to create sculpt prim based stairs. Stairs are really prim consuming in SL and the idea of having one, shaped in a single prim, was very interesting to me. Furthermore, with the right modeling, the bounding box can really fit the stair shape -> this leads to a greater collision detection behavior than any of standard prims based stairs. But so far, despite many tries to have the sculptmap being rendered correctly after compression, I just get no acceptable results, even if I try increasing the size of the texture or even try a standard jpg compression on my PC to see which colors will be affected and tweak it consequently. So compression is not good for non-organic shapes. This has lead me to think that such shapes (stairs, guitar bodies, anything which should at least have one strict plane or strict sharp edges) have less information to store about the position of their vertices. Stairs are aligned, top and bottom of a guitar body are parallel, etc ... In term of number of informations, this reduces the quantity a lot and could be exploited for other types of compression if still needed. I believe in the case of my stairs (23:10 steps x 5:topright, tl, bl, br & tr to close = 115 vertices with 23 different R,X values, 2 for G,Y and 3 for B,Z), just a 'stupid' zip compression would lead to better compression and viewing results than a jpeg2000 one. I hope these considerations will be helpfull. --Roms Maertens 01:47, 26 May 2007 (GMT+2)

I understand that LL wants to leverage image processing technology when using these prims, but I really think we need something lossless. How about a 32x32 lossless map, and we can use a 32x31 grid? If we really need to close the figure, just put that pole point at the geometric center of the final "ring".--Watermelon Tokyo 10:31, 27 May 2007 (PDT)

Well actually you can get lossless compression on your vertices by "abusing" how it works. The subsampling for textures larger than 32x32 is absolute and does no averaging. Hence in a 128x128 texture only 1/16th of the data is used. So if you make a 32x32 texture and then scale it to 128x128 so that the vertices are big blocks of 4X4 pixels where the one that will be sampled is surrounded by pixels of the same colour than you're pretty sure that the compression will likely affect only the surrounding pixels and not your vertices. Obviously the net result is that the compressed 128x128 is larger than an uncompressed 32x32 but that's why we've been pushing for uncompressed 32x32 in the first place. The workarounds are a lot heavier than just having no compression for 32x32 and below. Let's hope LL stops compressing 32x32 in the near future or you'll soon see people using very large textures just for the sake of having their vertices unaffected by compression. Note: I'm not advocating the use of 128x128 to work around the compression, we should keep the pressure on getting 32x32 and below uncompressed. --Blakar Ogre 11:45, 27 May 2007 (PDT)

To me, sounds like you have baking texture from 3D Max or Blender issue. Cause the baking is like rendering lights onto the model but few times I found out that the model had smoothen surface when rendering. Which blends the color more around the corners and edges. Make sure the models doesn't have any smoothen surface and or Anti Aliasing rendering on baking texture. --Vincent Nacon 21:40, 18 May 2007 (PDT)

Sounds reasonable, Vincent. I'll look into it. Also, I've nearly completed a maxscript to render the output without baking. So, I'll report how that works out. --Shack Dougall 09:10, 20 May 2007 (PDT)

I'm getting much more accurate results in the last two releases. I think Qarl must have tweaked the compression algorithm. --Shack Dougall 20:55, 22 May 2007 (PDT)

No, I think I just improved the method I was using and maybe had some wishful thinking. It's still a big problem. --Shack Dougall 18:41, 3 June 2007 (PDT)

Symmetrical Polygon Sides

The problem I'm having with sculpted prim after getting finer details, all triangle polygons are facing same way in a flow of the sculpted prim itself. Wondering if Qarl could make a minor change on sculpted prim's meshes at half way mirroring the triangle in other dircetion, flipped. So some creation can have both sides to be symmetrically mirrored from right at the middle.

Like this picture as a example, top and bottom are the polars, at half way, it flip around.

Maybe add checkbox to set Symmetrical Polygon Planes? --Vincent Nacon 10:44, 25 May 2007 (PDT)