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