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