ChinRey
-
Posts
8,380 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by ChinRey
-
-
20 hours ago, ChinRey said:
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.
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.
20 hours ago, Wulfie Reanimator said:It doesn't create a flat surface (at least with the smallest brush), and the gradual raises mean that it doesn't create sharp edges either. You can totally have a script create gradual slopes -- not perfect, but maybe it's good to have a little bit of variance in nature? (Just grasping at straws here. The owner might want to clean up the result.)
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! 🙂
-
1
-
-
21 hours ago, Quistess Alpha said:
not to mention the letters won't fit together horizontally nicely unless it's a HUD or you're looking at it straight on.
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.
-
1
-
-
Thanks a lot but there is one problem here:
1 hour ago, Wulfie Reanimator said:// Here we have the height difference between the ground and the plants. // This can be used to raise the ground to meet the plants. heights += point.z - ground.z; } llOwnerSay("Ground needs to be raised by: " + llList2CSV(heights));
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. 😞
-
9 minutes ago, Wulfie Reanimator said:
If you reject physical, non-physical, and phantom objects for the raycast, it'll only detect the ground without fear of hitting itself.
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.
-
1
-
-
3 hours ago, Wulfie Reanimator said:
Or is the problem still about being able to create a correct slope, or pick the correct spots to raycast from?
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.
-
43 minutes ago, hinaichigo Xaris said:
I HAVE A QUESTION!
What does PBR mean?
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.
-
2
-
-
9 hours ago, Wulfie Reanimator said:
You can change the precision from the Grid Options window (when you press the right-arrow in the edit window).
That's a very good tip but user configurability is still not a substitute for good default design.
-
2 hours ago, Bold Burner said:
does anyone have the exact number to put in Path Cut to achieves this?
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:
-
1
-
1
-
-
55 minutes ago, Elsa Ewing said:
For maybe obvious reasons I will not support RFL in this case.
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!
-
4
-
-
5 hours ago, Henry Blackwood said:
Abandoned land is kept in hand by LL for seven days
At least seven days. Usually it takes months, even years before an abandoned parcel is back on the market.
3 hours ago, Cate Foulsbane said:AND made it clear that I'm not the first person to make this mistake.
You're not. I know because I've done it myself.
-
17 hours ago, Cate Foulsbane said:
I finally calmed down enough to remember how to deal with abandoned land. Submitted a ticket, fingers crossed they let me buy it back
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.
-
2
-
-
2 hours ago, AmberJoyBliss said:
what else should be on the checklist?
Best advice, make sure you have access to the beta grid so you can do test uploads without wasting money on them.
-
2
-
-
On 1/18/2023 at 11:11 PM, Kimmi Zehetbauer said:
Faster loading on slower machines then Mesh.
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.
-
3
-
-
5 hours ago, Marianne Little said:
I wish we could have more tools to use with prims. A tool that smooth out edges and corners, to make rounded corners and rounded edges.
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.
-
4
-
2
-
-
1 hour ago, Lindal Kidd said:
I like prims because I understand them and can build with 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.
-
9
-
1
-
-
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.
-
5
-
2
-
-
20 hours ago, 2Tessa said:
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.
-
4
-
-
21 hours ago, Coffee Pancake said:
Linkset size :
1prim = 1li
2 prim = 1li
10 prim = 1li
20 prim = 2 li
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.
-
8
-
-
47 minutes ago, IvyTechEngineer said:
Also, what does Step 3, Simplify do?
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.
1 hour ago, IvyTechEngineer said:A physics model can be created from a LOD for a model.
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.
-
1
-
-
7 hours ago, arisaie said:
but what will happen if everyone upgrades their mesh with 4k textures?
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.
-
1
-
-
4 hours ago, LittleMe Jewell said:
Yeah, I finally found the various Grumpity posts (and added them somewhere above), but I apparently missed out on the cancellation notice.
I don't think there ever was a cancellation note and I may have made that part up.
-
1
-
-
1 hour ago, Hotbabe2004 said:
Any idea what is happening?
Yes, a few, but it's hard to tell without more details. Could you post a screenshot of the upload window here?
-
On 1/10/2023 at 7:54 PM, LittleMe Jewell said:
I'm pretty sure it was @Dakota Linden that promised a pony a few years back when the price of Premium first went up. She just kept saying that they must have gotten lost in the mail.
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.
-
1
-
2
-
Facebook
Instagram
Twitter
YouTube
Flickr
Is there a mathematician in the house?
in Building and Texturing Forum
Posted
Yes, that's the way it would have to be done in SL. It's still frustratingly complex though. You need a way to define the boundaries for the landscaper prim, you probably need some way to pause the script regularly since doing it this way in one go may well overload the scripting engine and above all, llModifyLand(() simply isn't suitable for the task. LAND_RAISE and LAND_LOWER won't give the precision needed whilst LAND_LEVEL will create steps rather than smooth transitions.
The reason it works on opensim is that osl has a function, osSetTerrainHeight that can be called from anywhere in the sim (so no need to move the editor around) and sets the elevation for individual terrain vertices. Maybe we shuold campaign for a similar function to lsl? Or maybe not. There is a reason why the osl docs marks the function as "High Threat Level".