-
Posts
8,372 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Everything posted by ChinRey
-
It can be a "ghost prim" an object that was deleted but for some reason are still in the physics engine. Or it can be some dodgy ground physics. In either case restarting the region should fix the problem. The regular weekly restart may not fix it though but if you ask LL to do a more thorough reboot, the problem should go away. Edit: It can also be a nearby with dodgy physics. Sometimes a sculpt or a mesh can have a bounding box and physics shape that extends well outside the visual shape.
-
Ok. I don't really have much to add to the replies I posted to those threads but I think I should emphasize one crucial and often overlooked trick I mentioned in both: If you want to ensure seamless joints between two meshes, make sure the overall dimensions of each and the position of every single vertice along the seams are a precisely a number of millimeters that is divisable by 2. If you don't it can be very difficult, even impossible, to align them correctly in-world.
-
No, that's a different issue. The download weight, which is the weight that usually determines the land impact, is calculated from two factors, the calculated swap distances between the four LOD models (which again depend on the size of the object's bounding box) and the file size of each of them. The file size depends partly on the amount of raw data of course but also on how much the compression algorithm (good old gzip) can compress the data and even minor differences in the data structure can have a significant impact on that. Here's a seriously oversimplified digtal example to illustrate. Take the string 1000010000. It can represented as 2x(1+4x0). But move the 1 in the middle to 1000100000 and we get 1+3x0+1+5x0, a significantly more complex string. No, there's no optimal triangle size, the rule is always to have as few as possible (but not fewer). However, with small triangles you usually need more of them, increasing the file size, and big triangles take up a lot of space, increasing the object size. So by combining them into a single mesh, you get both a relatively large and bounding box, increasing both the factors that determine the download weight. So the general rule is to not combine big and small tris in a single mesh. But remember there is no rule without exceptions. Look at this little cottage for example: The doorframe has 24 small tris and the window 28 so normally we want those as separate meshes. Normally they shuold have been done as separate meshes but this is a 1 LI house so it can only have two parts in the linkset. The door has to be separate to be movable so everything else had to be made as a single mesh. This is a good example of how the different rules for optimisation conflict with each other so you have to choose one or the other.
-
Awww, I didn't notice your post until now. 😉 It makes no difference whatsoever so do it the way you prefer. I'm not sure I understand the question. Can you give us a link to that 2017 post you found? Here are a few general rules for splitting a mesh into a linkset though: Try to keep the distance between the center of each part to less than 64 m. If it's bigger, you won't be able to link them. (This has changed since 2017 btw, the max link distance used to be 54 m.) If possible, avoid splitting parts that have the same texture. It's no big deal if you have to though. For optimal LOD and LI split big and small tris into separate meshes. For optimal LI, try to get the download weight and server weight of the linkset as equal as possible. If the linkset includes several identical elements (such as windows on a building), upload one copy and duplicate it in-world. These rules often conflict with each other so be prepared to make some compromises. Well, it's always easier to give feedback to a finished build than to some abstract questions so that can't be avoided. But you do know about the beta grid, right? You can do test uploads there for free and that's crucial if you want to improve your meshes without wasting tons of L$.
-
The only way I can think of is to use one or more flexiprims. A single flexiprim with a good chain texture should work quite decently and with four synchronized flexiprims you can make a chain that looks convising even at close range. Edit: On second thought, maybe two would be enough, not four.
-
Yes, that's potentially a great use for Second Life. I assume you want your students to be able to walk around inside the house to get a feel of how it works and that causes a few problems. SL avatars tend to be considerably bigger than RL humans so you want to make special avatars to match RL scale. The default camera position far behind and above the avatar won't work inside an RL scale building and even a modern "game style" camera position is too far off to really give the level of immersion you need. So you want to go into mouselook. Both these issues can be solved when you're aware of them but there's a third one, walking speed. In SL it's about twice as fast as in RL. Try to move around in your RL house at a brisk jogging speed and you see the problem. A don't know any solution to this unfortunately. The CtrAltStudio viewer, which was specially made for VR headsets, solved it by continuosly starting and stopping the movements but I don't think any current viewer has any similar function.
-
I haven't researched it but I can't imagine it would make much difference. If you have 78 faces, presumably with 78 different textures, the load caused by the geometry is a drop in the ocean compared to what the textures cause. So choose whatever suits you.
-
That's an advanced question, certainly not a noob one. Second Life does not have object instancing (yet) but there can still be a lot to save by assembling objects from a few standardised modules rather than making them from big single meshes since it can drastically reduce the amount of data the client has to download (or retrieve from cache) and process. The most render efficient way to make a tree would be to use a few such modules for the trunk and branches and make the foliage entirely from prim sheets. That would mean a huge icnrease in the land impact though. Land impact has nothing to do with render efficiency, it's all about server load and as far as the server is concerned, an object is an object. It doesn't matter if it's a high poly mesh or a simple prim and it doesn't matter if it's part of a linkset or not. (The latter is a fundamental flaw in SL's software btw but it's one that would be horrendously difficult to fix now.) One of the biggest secrets of efficient building is to find the right balance between render load and land impact. This is a bit of an art really since there are no absolute rules and every case is unique. For trees, splitting the canopy is definitely a part of this balancing act. If you look at the two trees in picture above, the small one has a canopy made from a single mesh. That's the only way to get the LI down to 1 and the foliage only has 24 tris anyway so it's hardly going to affect the load. The big tree, however have a canopy made from three different meshes, some of them copied so adding up to seven parts. With that being said, textures are still far more important for render load than geometry and there's a lot more to save by re-using textures than meshes.
- 8 replies
-
- landscaping
- lod
-
(and 1 more)
Tagged with:
-
Oh, I hope you don't misunderstand me. It's perfectly possible to make good looking low LI high LOD trees without going all the way down to crossed panels. Take these two trees for example. The one to the left is 21 m tall and 4 LI, the one to the right 10 m and only 1 LI yet (you have to take my word for it here) they never disappear or even distort noticeably until you go beyond your veiwer's draw distance. The trees from the creators I mentioned in my first post are not quite at that level but they are close enough I'm sure you'll be happy with them. Ummm, I think my picture prooves you wrong there. Mesh can do that but there are only a handful of mesh makers skilled enough and very few of them make trees. But sculpts do make a lot of sense for very big feature trees as long as you don't have too many of them and Lilith Heart's old oaks are still among the best there are in SL in that category.
- 8 replies
-
- landscaping
- lod
-
(and 1 more)
Tagged with:
-
If You Divided the SL population into two groups
ChinRey replied to BilliJo Aldrin's topic in General Discussion Forum
This isn't nice of me but often in the past (not so much recently) I've had the feeling the SL population could be divided into: 0. People who's opinion doesn't matter 1. Programmers -
Ok. His cedars aren't too bad actually. At least not from what I've seen. I never needed cedars myself so I never looked too closely at the options for that particular tree.
- 8 replies
-
- landscaping
- lod
-
(and 1 more)
Tagged with:
-
Off the top of my head I can only think of four mesh tree creators who fit that bill: Reid Parkin (Mesh Plants), Alex Bader (Skye), Teresa Matfield (T-Spot) and one I'm not allowed to mention here. I'm sure there are a few others too so let's see what others recommend. --- Edit: No, make it four. I completely forgot Eldowyn Inshan (United InshCon) since I never got around to use any of her works on my own sim. I've also seen low LI/lag trees with good LOD by others but I don't know of any who does it consistently. I was in a similar situation as you about ten years ago, building a two sim landscape with low lag and long distance visibility. In the end I had to learn how to make trees myself but even after that I was still happy to keep the Teresa Matfield and Alex Bader ones I already had. (Reid Parkin's trees weren't on the market yet at that time as far as I know.) They weren't quite up to the standard I wanted but close enough not to cause any serious issues and far better than most mesh trees on the market. ---- Edit 2: If you want low lag, low LI and good LOD lush vegetation, it's important to think in layers: Very simple (even down to old style crossed panel) meshes for smaller plants and plants that are well away from where people are likely to go, well optimized medium detail plants (like the ones from the makers I mentioned) for the bulk of trees and then a few highly detailed mesh or sculpt(!) ones in strategic spots. The two Grand Old Ladies of SL trees, Lilith Heart and Nadine Reverie are worth checking out for the latter. I already posted a message about this long ago so I won't go into details here. Take a look at https://community.secondlife.com/forums/topic/465598-plants-lag-and-a-new-classification-system-for-vegetation/
- 8 replies
-
- 1
-
- landscaping
- lod
-
(and 1 more)
Tagged with:
-
Just a quick comment without reading the whole discussion (sorry, I'm a bit busy atm). Normally the edges are the last place you want to simplify a curved surface because that's where the angles between the vertices are most visible.
-
That's a very good point. SL is only free for people who need the hardware anyway and most people don't.
- 66 replies
-
- 2
-
One thing you can try before you simplify the physics model is to increase the height of your terrain a bit. It's a bit counter intuitive but SL's physics engine doesn't like small meshes and at 1 m you're close to or past the limit where the physics weight starts to skyrocket. If you end up simplifying the physics, you may want to consider simplifying the main model to match too. For walkable surfaces it's often more important to maintain a perfect match between visuals and physics than to add lots of details.
-
There's nothing you need to do to make it mesh compatible but you do want to tweak those shape sliders to get the best result. It's not about system vs mesh body either. Each mesh needs its own tweaks. It's always the combination. Even the best shape can look bad if the skin doesn't fit it and vice versa.
-
find people to build together
ChinRey replied to Lisa Schlesinger's topic in Building and Texturing Forum
I don't know of any hang out places for builders but you should really join the classes at Builder's Brewery and also at Happy Hippsters. Not only are they great for learning building skills but also to meet other builders. -
One rather important question then: are there still people running Widows 8.1 or earlier here? If so, they may not be able to even run the current versions of the viwers, let alone future ones. Now, Windows versions before 10 are not officially supported by Second Life and I have no idea if this is a genuine problem, which is why I ask. But it's definitely something we should consider.
-
There are still a lot of aspects of "full PBR" that are missing and for good reason. For those not too familiar with the concept, the idea with Physical Based Rendering is that instead of simply reproducing the colors across a surface, we try to simulate all the physical factors that cause those colors. But there are so many such factors and they interact with each other in so many weird and wonderful ways. If we were to take PBR all the way, we would have to measure render lag in frames per year, not frames per second. Some people wouldn't be happy about that so we have to compromise a little bit to make it work.
-
Slightly, but not completely, off topic: To understand this, it's important to realise that PBR is not a standard. It's a concept with a lot of different implementation. This is why there is so much confusion about the names of various maps. The Khronos Group is trying to establish a standard for it now, based on Unity's old PBR system. But there are still lots of other variants around and there will probably always be, partly because some won't change, partly because glTF PBR is a very simplified take on the concept and may not be advanced enough for many uses. The SL software very often does a better job scaling from 2048 to 1024 than the most common scaling algorithms used by various image eitors. It's a bit of a hit or miss though and if you really, really, really want to make the most of each pixel and are willing to spend some time and effort on it, head over to the beta grid and try different scaling methods (including the one built into the SL software) and see what works best.
-
Well, it gave us an opportunity to point out that there are actually SL builders who take LOD and the other technical aspects of 3D modelling seriously. As far as I know, the flickering is caused by the draw distance. It happens when an object is right at the limit. That would be really useful. I think I spend more time minimizing the "jumps" between the LOD models than I do reducing their tri counts. It's more about normals than geometry btw. You get those surfaces that suddenly brighten up or darken when the LOD models are swapped. It's dead easy for a model like the tree in Animat's pictures but very often it's a serious headache. This is also arguably the biggest flaw with auto-generated LOD models; neither GLOD nor MeshOptimizer seem to take normal vectors into account at all. (Pro tip btw: Using custom normals to transfer normal data from the main model often often helps. Not always - sometimes it even makes matters worse - but often enough it's well worth adding the trick to your arsenal.) I'm not sure if there's that much point if it's only implemented by one third party viewer though. There are two more advanced solutions than cross-fading, tesselation and morphing with defined paths between the LOD levels. Those would require drastic changes both to the server and client software and even to the content creation work flow so they are not realistic options. I think there are a few AAA games that use tesselation but not many and as for morphing, I'm not sure if the technique has even been invented yet. Maybe I should patent it?
-
It's a bit hard to comment since the trees in the picture aren't here anymore but judging by the picture this looks similar to some of my 1 L$ budget trees, apart from the blur and a slightly different texture that is. In any case, all my trees have better LOD than this and so do Alex Bader's and Teresa Matfield's just to mention two others. Animats knows this perfectly well so I'm not sure what he's trying to say here.
-
Oh, I see. Yes, the problem with high reflectivity and normal maps is well enough known.
-
I haven't noticed such issues in any of the PBR materials I've made so far but I haven't done that many tests and it's all been brick, stone and wood textures that don't need that kind of precision. So I can hardly claim to know everything about it (yet). It does make sense then. Of course, if you want max optimization for performance, the way to do it is to try upload the maps separately first and switch to uploading a complete material if that doesn't work out but I wouldn't hold it against anybody if they're unwilling to make that effort for a fairly minor performance gain. Btw, I assume I'm not the only one to realize that this means we now can upload any texture or surface map with lossless compression. Just put it in the normal map slot of a glTF material and off you go.
-
It's not my problem, I'm uploading so many textures these days I had to switch to Premium Plus anyway but you're saying that If you want to convert an old style texture to glTF PBR you are supposed to reupload everything and If you have a dozen or more color variants of a texture you are supposed to upload separate duplicates of the normal and metallic/roughness maps for each. There's gonna be a helluva lot of duplicate assets to store, download, cache and render this way. Of course, there's a fairly straightforward workaround for #2 but how many are going to use it or even known about it? Yes and no. If LL is implementing true mip-mapping, it may well be time to retire the lossless compression. But if so, why only for normal maps? It makes just as much sense to switch to lossless compression for textures and diffuse/albedo and roughness maps.