ChinRey

I was wrong. It turns out the open source land editing script I've been using runs llModifyLand() inside an infinite loop which is why it always maxes out the effect applied. Applying the function a single time does, as Wulfie observed, cause aproximately 0.2 m of change. Yes, I don't think it will be close enough to be worth the bother, especially with all the headache trying to get llModifyLand() to do the job. However, your suggestion using raycasting gave me an idea for a completely different project. Look at this: Just a pile of prims on a flat ground. Raycast and apply to the terrain and I get this: It only really works on opensim, not in SL, since opensim does have a straightforward way to position terrain vertices individually and precisely. But even so, this is going to be really useful, thanks a lot Wulfie! 🙂

You can actually achieve consistent letter alignment regardless of view angle: This has the six prims postioned at exactly the same spot with whitespaces used to position each letter. It's not something I would recommend but it is possible.

Thanks a lot but there is one problem here: There is no lsl function that allows you to raise or lower the ground by a specific amount. If I remember correctly, llModifyLand()'s LAND_RAISE and LAND_LOWER actions only raises/lowers the ground way up into the sky or way down to the bottom of the ocean and as far I know they have no practical use whatsoever. It's either that or they jsut produce a tiny little barely noticeable bump in the terrain. In any case, there's certainly no way to use them to set a specific level, neither absolute nor relative to the starting point. The only even theoretically possible way to do this in SL is to use a separate prim that moves from point to point using the LAND_LEVEL action like this: llModifyLand(LAND_LEVEL,0); That means there is no need for the script to know the ground altitude before the process so raycasting becomes irrelevant. All the script needs to know is the exact height of the mesh exactly above each vertice on the ground underneath. (Or maybe exactly between four vertices but that'll be a trivial issue to sort out.) And then of course I'll have to figure out a way to smooth out the terrain without lowering it. LlModify land doesn't manipulate individual vertices but only groups of 4, 16 or 64 so the result won't be a smooth slope but rather a series of sharp steps. Maybe this is a bad idea and I'm just wasting your time and mine here. 😞

Yes but I think you misunderstand me a bit. I have no need for raycasting the existing ground level, I need to determing the level the ground needs to be raised to. Look at this group of bare shrubs for example: It needs a ground level something like this prim: One solution is of course to put a prim like that on tha spot, raycast it, remove it and then rez the plants on top of the new ground. But that soultion is seriously awkward, especially if the plant group is to be resized and/or rotated.

The problem is that those meshes don't have solid bottom surfaces and there are bits and pieces sticking up all over them. I can of course add a template mesh or prim that matches the bottom of the mesh and raycast that template but that's a complication I'd rather avoid if possible.

This is a bit embarrasing but my head is a bit mushy right now and high school maths is many years away. I have a wedge like this and I need to calculate the height of any given point of the top surface. Or more precisely: I need to calculate the height above each vertice of the ground the wedge covers. So far it's dead easy, my brain isn't so mushy it can't do simple additions and subtractions. 😉 But what if I rotate the wegde? and what if it's a semisphere rather than a wedge? In case you wonder why I'm asking, I have these plant groups with several plants in a single mesh specially made to cover slopes and hilltops. It saves a lot of LI and lag compared to using single plants but getting the ground to match can be a real pain. I'm trying to come up with a script that does the terraforming automatically.

Physical Based Rendering. It's a fundamentally different concept to texturing; rather than a texture giving the color for each point on a surface, PBR attempts to replicate the physical properties that cause a material to have its color. Strictly speaking we don't use the term correctly in games and virtual worlds. It's still not possbile to replicate all the physical laws of RL in a real time virtual reality so PBR for us is a bit of a mix between premade textures and dynamic physical based effects. It's not actually something brand new in SL. Even the old legacy bumpiness maps and shininess effects are arguably a very primitive take on game/vritual world style PBR. What's new is that LL is taking the concept several steps further to match what more modern game/virtual world engines have to offer.

That's a very good tip but user configurability is still not a substitute for good default design.

It's simple maths actually. 30 degrees is 1/12th of a full circle so the pathcut you need is 1/12th or 0.08333333333333333333333333333333333333333333333333333333333... Note that this is the difference between the start and end values. If you only want a single slice, you set start to 0 and end to 1/12. However, if you want a pie chart, it's easier to use consecutive numbers. That way the slices automatically align perfectly with each other. If for example you want several 30 degree slices, you set the pathcuts for the first to 0 and 1/2, then copy the end value and paste and add +1/12 for the end value of the second slice, paste the end value for the first as the start value for the second and so on. Edit: This may be something not everybody are aware of but you can do simple maths - additions, subtractions, multiplications and divisions - in the entry fields in the editing palette. This can be a very useful trick in many situations. But keep in mind that Firestorm has some pesky "overflowing" decimals and they can cause some serious problems if you're not careful. Look at this for example: I want to move this prim 1 m along the x axis so I type in +1 at the end of the value there: And the prim jumps not 1 m but 14! The reason is that there is a hidden decimal in the field: This is a noob mistake in UI design of course but it's not likely it will ever be corrected so we just have to lvie with it and remember to always move the cursor to the end before you start typing:

I don't know which reasons you have but yes, I'm with you. I wouldn't call RFL/ACS a hoax since they are quite open about how they operate but only a quarter or less of the fund they raise is actually used for cancer research and aid to cancer victims (aid that would be covered by the government in a well functioning society anyway). The rest is spent on fund raising activities and "administrative costs". The CEO actually makes more money than what RFL manages to raise through Second Life! To be fair, they have improved their act in recent years, they used to spend up to 90 percent of their money on their own organisation but it's still not anywhere near good enough. If you want most of your money to be put to good use, take a look at Spoonful Of Sugar. They are raising money for Doctors Without Borders, one of the world's most respected and most efficient charity oranisations. I'm not sure if they accept donations outside their yearly events but contact Ever Courtis and ask. I'm sorry to hear you are leaving SL ut I can understand why. I hope we'll still see you in That Other Forum That Must Not Be Mentioned though. I've always appreciated your thoughtful - and sometimes humorous - comments there!

At least seven days. Usually it takes months, even years before an abandoned parcel is back on the market. You're not. I know because I've done it myself.

Unless LL's policy has changed recently, they'll just give you back your land if it's the first time you've had this accident. It make take a few days for them to process you ticket though.

Best advice, make sure you have access to the beta grid so you can do test uploads without wasting money on them.

Every single possible shape in the current prim system are generated from a dataset of less than 60 bytes. This is less than half of what a single mesh triangle with its vertices needs. So even the simplest mesh will always take longer to load from the assets server or from cache than the most complex prim. The viewer's render pipeline also handles prim data more efficiently than mesh. Some tests I've done indicate that when it comes to actual render weight, one mesh tri as roughly equal to 20-50 prim tris. I'm not sure if this is because the viewer is better optimized to handle prims or if they are genuinely easier to handle for our cpus and gpus than polylist meshes but I believe it's a little bit of both.

A long and rather techy reply. Sorry about that, I'll get there in the end but I thought it was time to look at what a prim really is and maybe what it could become. Any prim is made from a combination of two simple two dimensional mathematical cruves. It starts with a profile. SL prims support four of them, a triangle, a square, a circle and a semicircle: To add an extra dimension to the shape, we extend it along a path. SL prims officially support two paths, a straight line and a circle. (There are also two weird paths that aren't officially supported but I think we should leave them out for now.) If we extend the triangle along a straight line, we get a prism, the square becomes a cube and the circle becomes a cylinder: If we extend the profiles along a circle path, the triangle becomes what SL confusingly calls a "ring": The square becomes a "tube": The circle becomes a torus: and the semicircle becomes a sphere: Those are the seven basic prim shapes we have, all based on just five (or really only two with variations) very simple mathematical curves. What if we added a few more curves? How about a squircle: Or a rounded square: There's your smooth edge prim! The mathematical formulas for these shapes (and many other potentially useful ones) aren't that much more complicated for a computer to handle than the ones it has to deal with for the current prim shapes and in theory it's dead easy to add them to the system. Unfortunately, reality isn't always as simple as theory. LL made a lot of changes to the prim code during the first few years before they lost interest, sometimes as misguided attempts to make it more "user friendly", sometimes for... for reasons. Beq once called it "loose code" and she didn't mean that in a nice way. TheBlackBox had to reverse engineer the whole thing when he made MeshStudio and he once told me in detail how hard it had been to figure on what on earth was going on. Back in 2008 Avi Bar-Zeev, the inventor of the prim, tried to write an article about How SL Primitives [Really] Work but he gave up when he saw what LL had done to his code after he left the Lab. It would probably have been easy to go back to Bar-Zeev's original code and take it from there but that might well break some existing prim builds that are based on the current standard. --- While I'm on this rant, take a look at this: https://drajmarsh.bitbucket.io/supershapes.html This is an online shape generator based on the same fundamental principles as prims but using much more complicated curves. Something like this would not be very useful to us of course, the shapes it generates are way too high poly and they are more fun than practical anyway. But there's a vast range of possibilities between this and SL's basic prim system and I so wish we had the chance to explore at least a few of them.

Just like Lindal I like prims because they are more user friendly for builders than mesh and also because they potentially are by far the most resource efficient type of virtual world content anybody has ever managed to come up with. But most of all, I love them because they are fun to build with.

While we're at it, why not also expand the prim twist options. The current prim system is based on only five basic two dimensional shapes that can be combined in various ways and then modified by 15 simple parameters. Avi Bar-Zeev's original prim generator software only had a few hundred lines of code and it could still generate all the prim shapes we know today and even a few that have been nerfed away from SL. There are so many other basic shapes and modifiers that could easily have been added.

As others have already said, we definitely do not want prim-to-sculpt converters! They are just a way to cheat the system by taking advantage of the fact that sculpts have much, much lower nominal land impact than they should have had. Prim-to-mesh converters can be great for prototyping but if you want a reasonably good mesh, you need to clean it and make proper LOD models up in Blender or Maya or such and once you do that, you might as well use Firestorm's built in converter rather than waste money on something else.

The bottleneck here is how SL's server software handles linksets, or rather how it doesn't handle them at all. Apart from the physics of course, an object is an object as far as the server is concerned. A simple prim cube is just as hard/easy for it to handle as a 60,000 tri mesh and each and every part of a linkset is treated as a separate object. If LL could upgrade the server software to treat a whole linkset as a single object even 50 prims could be reduced down to one land impact.

It does exactly what it says, it attempts to reduce the number of hulls for the physics model. But with that being said, you do not want to use analyzed physics for a terrain mesh since you'll never get good tracking that way. Analyzed physics also tends to end up as much heavier than unanalyzed for large irregular meshes like this - another reason for not hitting the Analyze button. If the terrain is suppsoed to be walkable, you use the high model as the physics, no analyzing or anything else fancy. If it's not supposed to be walkable, use a cube as physics and set the mesh to phantom after you've uploaded it. Not created from, it uses the LOD mkodel you choose directly for the physics. That's not relevant in this case however since the only correct way to handle LOD for a mesh like this is to "use level above" all the way so all four LOD levels are identical.

We'd end up with SL scenes containing tens of thousands of 4k textrues and surface maps, more than enough to make even the strongest game computer in the world to crash and burn.

I don't think there ever was a cancellation note and I may have made that part up.

Yes, a few, but it's hard to tell without more details. Could you post a screenshot of the upload window here?

No, it wasn't Dakota, it was Grumpity: https://community.secondlife.com/forums/topic/428968-town-hall-meeting-with-grumpity-oz-and-patch-linden-november-15/ In the end they had to cancel it because it turned out the ponycount was already too high in SL.

Yes but remember we're not talking about whether backfaces are good or bad in themselves right now but rather whether they should be defined as part of the geometry or the materials. I was actually going to post a similar comment to yours earlier but then Arton gave me second thoughts. Defining backfaces as part of the geometry is only likely to increase the number of redunant tris since creators then are more likely to add backfaces to entire meshes, not to separate faces. The solution is of course to only use automatic backfaces when a substantial part of a submesh need them and do it the old way with duplicated flipped normal tris if it only applies to a small part of it but how likely is it that the average SL mesh maker will realise this? But oh well, backfaces are coming to town whether we like it or not. You did but no problem as far as I'm concerned. Being credited for one of Arton's comments is only flattering. Btw Beq. Since I have your attention, I have two Fs questions unrelated to this. Sending you a PM.