Macrocosm Draegonne

I have to put a video up of it once its in world, the texture and mesh needs some more love first though, plus I have to put more plants in the same texture to save draw calls. With animated leaves the texture density needs to be thinner too. I made the grasses from scratch in Blender, hand painted mesh + material effects, then baked planes. Im guessing once I get enough of them out there in a scene the next hurdle could be the timing between them, Im hoping that being based on the wind which is different in different areas will give enough diversity, but I would wager I need to add some more still time to them to make the effect even more subtle most of the time, Ive still got to play with the if/else logic some more today which should do that fine

Oh I see now, the llWind wasnt there, thats why the separated one was working and not the other, it needed that function to get the right connection stack going. I was almost figuring that out but not quite there hahaha, I knew something was off but I didnt detect that missing llWind, which should have been apparent but I guess im still a newb and thats going to keep happening until I scream and learn more.

When testing float windSpeed = llVecMag((ZERO_VECTOR) ); I get zero's as a result with that for some reason when testing the output, is there some caveat about needing to separate out with this below? vector windVector = llWind( ZERO_VECTOR); float windSpeed = llVecMag( windVector); I will keep testing for sure, but I can say the float modSpeed = windSpeed * 0.05 works perfectly. that indeed is a much cleaner and more concise line! I was beating around the bush there a bit lol ? Now that I a bit more fully understand things I can add in some If/else logic to treat the high and low wind differently in the animation which should be a nice touch hopefully, and can add some more still time to it as well perhaps

Thanks so much for that, I will test for sure, there was still some cruft in there from other testing too heheh, but also the numbers are very very touchy in the llSetTimerEvent, so it caused me to try some odd combos in the functions to try and make it calmer, especially in that line I brought over from the sailing script, also in that last paramater section too, may times I would get no animation, or the texture would split and freeze. I tried to look for some others like and opposite of llPow to replace that bit with but nothing jumped out as I was checking, I figured that line was the most messy of all and would need refactoring, if not the whlole script, but I still was very happy to get it down to a very subtle effect comparatively.

Ill put this one up now, its much better for what I had in mind, and of course is reliant on my UV setup as mentioned above in the thread. I am certain I will make this several times over again as I learn more and can do more, but I am happy now and should jump back to the graphics and mesh side of this to further enhance it on those fronts. Thanks everyone for the encouragement and super useful pointers! // Texture Plant Waver Chingus Based On LL Wind Speed // Script should be deleted after activated. float CYCLES_PER_SECOND = .06; integer FACES = ALL_SIDES; // Change if you want just one face float ANGLE_DEGREES = .8; default { state_entry() { llSetStatus(STATUS_PHANTOM,TRUE); llSetTimerEvent(4.00); // trigger timer event (max once per second) } timer() { vector windVector = llWind( ZERO_VECTOR); float windSpeed = llVecMag( windVector); integer windValue = llRound(windSpeed); float modSpeed = .1*llPow( llVecMag( windVector), .333333); // moderated speed //float windDirection = llAtan2( windVector.y, windVector.x); //integer compassWind = ( 450 - (integer)( RAD_TO_DEG*windDirection))%360; llSetTimerEvent(1.0+llFrand(12.0)); //trigger the timer event every 12 seconds float angleRadians = ANGLE_DEGREES * DEG_TO_RAD; llSetTextureAnim( ANIM_ON | SMOOTH | ROTATE | LOOP | PING_PONG , FACES, 1, 1 // (These parameters ignored for ROTATE animation) , -angleRadians // Start angle in radians , modSpeed * .02 // Length of animation in radians ,CYCLES_PER_SECOND * llFrand(0.66) * modSpeed); } }

Yea, that was the right angle to go on, I have it much much more subtle now with more variation too.

I was able to modulate the number a bit with that function from the sailing script, however, its all very tinkery, I am almost there, but its still too fast and active compared to similar plant animations ive seen out in the realms, it keeps getting better as I learn more though. The trouble is as I tweak the number lower to get a slower speed the animation then breaks, and the texture splits up and/or stops moving all together. ? Below is my latest code tinkering with using the wind speed. EDIT: Improved by reducing the angle, so tinkering around more with that area more might yield more interesting results, to get a mix for low wind vs high wind. // Texture Plant Waver Chingus Based On LL Wind Speed // Script can be deleted after activated. float CYCLES_PER_SECOND = .04; integer FACES = ALL_SIDES; // Change if you want just one face float ANGLE_DEGREES = .3; default { state_entry() { llSetStatus(STATUS_PHANTOM,TRUE); llSetTimerEvent(6.00); // trigger timer event (max once per second) } timer() { vector windVector = llWind( ZERO_VECTOR); float windSpeed = llVecMag( windVector); integer windValue = llRound(windSpeed); float modSpeed = .1*llPow( llVecMag( windVector), .333333); // moderated speed //float windDirection = llAtan2( windVector.y, windVector.x); //integer compassWind = ( 450 - (integer)( RAD_TO_DEG*windDirection))%360; //llSetTimerEvent(1.0+llFrand(12.0)); //trigger the timer event every 15 seconds float angleRadians = ANGLE_DEGREES * DEG_TO_RAD; llSetTextureAnim( ANIM_ON | SMOOTH | ROTATE | LOOP | PING_PONG , FACES, 1, 1 // (These parameters ignored for ROTATE animation) , -angleRadians // Start angle in radians , angleRadians * .2 // Length of animation in radians //, llFrand(0.2) - CYCLES_PER_SECOND); //, windValue / CYCLES_PER_SECOND); , modSpeed ); } }

Oooh, thats interesting, I had not found that page when searching wind stuff. Really smart to peg on that 0,0,0 spot for consistency, I will tinker with that for sure, also I did not know you could sail the winds in SL, thats new to me also are very cool. Cheers!

Omg I have so many questions, I love learning a new language, you only get this feeling for so long heheh. I have had to stop myself so many times from coming here with a million questions, and then, no, get back to digging and testing, and tinkering. LSL is quite different than i am used to doing with web stuff. Im currently trying to reduce the number of the wind speed to fit nicely into the last section of the llSetTextureAnim anything too high and its really a bit much. ive tried all sorts of things. Using a simple division messes up on rare occasion when it falls below zero, the texture goes off all cockeyed. In my mind I want an array/list of values, I could use llRound to turn the windspeed into a single digit, and then on my array associate a small number to each range of those windspeeds, which then can be passed down to llSetTextureAnim in the last spot for Float Rate. But there are many other ways I could do this too, instead of float rate maybe tweaking the Float Length, or both? lol so many things to test, I imagine it will change a lot over time as I learn more.

windSpeed / CYCLES_PER_SECOND ? are we ok with using llWind on things? it works perfectly, no need to randomize the speed anymore, I just need make it more subtle and all of them in the area are now synced because, wind, wow this is cool! ?

Thanks so much for the tips and encouragement, I will dig into the wiki on that more and tinker with adding an extra ..llFrand(1) seems like it would be nice for them to go dormant from time to time. Im also going to switch to deal with linksets using llSetLinkTextureAnimation probably. Thanks for letting me know about viewer/server strain area too, I really wanted to be sure I wasnt going to hurt performance as that is a primary goal of mine. I am actually really pleased with how well it performs, and its super smooth too, once you get the numbers just right so its not jumpy, and let me tell ya, that texture animation can fly at blazing speed! lol made me dizzy a few times. I will be doing many weird things with it in due time I hope. Sometimes I really like the code to have a cozy macro view pattern, it helps me to jump into the different areas as the code gets larger and larger, especially when I am thinking of the code, I can mentally zoom in and out of the pattern lol. ? Im not sure what syntax highlighing to use in Brackets though, I saw some lsl ones in github but not for brackets. Luckily there is a GLSL one that seems to work nicely built into Brackets, and also the C syntax highlighters seem to look well enough too.

The randomization is working great but Im wondering if thats the best thing, maybe something of a preset thats seemingly random anim would be better performant for more people? I want this to be as lightweight as possible so I can have more plants moving, works great on my PC but im wondering if the timers are the best route? Also id like to introduce some spans of time with no animation so maybe adding a third timer cycle for that, or somehow injecting a zero in cycles_per_second on occasion? Are timers taxing on the viewer/server? Below is my latest code, feel free to laugh at my newbiness and poke holes in the approach lol. Its more properly formatted now at least. // Texture Plant Waver Chingus With Randomization // Script can be deleted after activated. float CYCLES_PER_SECOND = 0.02; integer FACES = ALL_SIDES; // Change if you want just one face float ANGLE_DEGREES = 0.5; default { state_entry() { llSetTimerEvent(5.00); // trigger timer event (max once per second) } timer() { llSetTimerEvent(1.0+llFrand(15.0)); //trigger the timer event every 15 seconds float angleRadians = ANGLE_DEGREES * DEG_TO_RAD; llSetTextureAnim( ANIM_ON | SMOOTH | ROTATE | LOOP | PING_PONG , FACES, 1, 1 // (These parameters ignored for ROTATE animation) , -angleRadians // Start angle in radians , angleRadians * 2.0 // Length of animation in radians , llFrand(0.04) - CYCLES_PER_SECOND); } }

Yeah, especially goodies like that, zero script need at all! I will have to thin out my grass density in the texture a touch, but I love the animation. It will take some tweaking to get the randomization and animation just right but its fun anyway. I want it to be really subtle and randomish. The most epic would be vertex animations dictated by Linden Wind and weight paint on the mesh, but thats not a thing here at the moment. The texture anim is a great fall back though, especially the more subtle I can get it. Im also putting several other plants on the same texture to save draw calls, so the uv map is going to be a lot of odd offset fun with this one hehe.

It worked! But I did it backwards lol, it will work next upload though, cheers!❤️ I would have never thought of that as a solution, I was all digging into a code solution.

Well, there will be flexymesh at some point, I saw that somewhere. Thats a cool Idea about flexies I bet it was great for grasses, and being able to tie it to wind is nice as well, I was reading the legacy linden tree's have a lot of cool features like that too, but they're gone now.

Yes I created the mesh and textures, though im not sure I understand fully what you mean by center. Move the uv section off the imagespace onto a repeat area in blender? Or change the texture so the plant image is in the upper space and thus the uv is as well?

I have some plants and want to animate the texture slightly, to make it feel like wind, I didnt want to use a sprite animation because that really inhibits texture quality. I've tried a few different ways, below is most recent. Trouble is its animating the texture from the center of the surface, making the base move as much as the tips of the plant and of course nill in the middle, are there any other ways to animate the texture that would feel more natural, like a fixed bottom and slow minimal pingpong back and forth at the top? Can I offset the rotation point? I had some randomization code in this before but that isnt the issue so I pulled it until I can figure this part. Im using rotation now, but I could go left right, rotation pingpong looks the nicest at the top though especially when randomized, still its not going to work as I outlined above. Ill keep digging, but theres not much out there on this topic. I'll post back what I find, but if anyone has any pointers that would be great too // Texture Wobble float CYCLES_PER_SECOND = 0.02; integer FACES = ALL_SIDES; float ANGLE_DEGREES = 2.0; default { state_entry() { float angleRadians = ANGLE_DEGREES * DEG_TO_RAD; llSetTextureAnim( ANIM_ON | SMOOTH | ROTATE | LOOP | PING_PONG, FACES, 1, 1 // (These parameters ignored for ROTATE animation) , -angleRadians // Start angle in radians , angleRadians * 2.0 // Length of animation in radians , CYCLES_PER_SECOND ); }}

Yes which is why its not that intelligent to use Sketchup for making game assets, the two tools are for very different purposes - Sketchup being a very limited set of purposes - Blender being the one app to rule them all, that nothing else on earth can compare too. The short time I spent with Sketchup was totally cut short because of my awareness of Blender lol.

Ahh, I see, they may not actually be in the viewer itself Those are some nice normals though! and wtf on those furry asses lol? ? Well, all the more reason to add a nominal collection of textures to the viewer, any of those textures would be zero bandwidth to load, and the more abundantly/creatively they're used the least amount of texture calls in the viewer too. Just an idea, Im not making demands or anything lol. More shaders, and texture atlas baking would be biggies too of course! My main point is that there are ample ways to reduce bandwidth, increase performance, and immersion, given how tech has progressed. Linden is in a sweet spot too, they have a solid established base with staying power, they can pick and choose from what best-of's to benchmark off of in the industry and slide it in, while all the others struggle to gain even a tiny fraction of SL's footprint, they will never catch up so long as LL knows when to eb & flow with innovations and evolutions.

Wow thanks for that detailed info, I was not aware of those aspects of prims, thats actually very interesting. I wasnt really speaking against what SL does though, more in general and future tense as literally nobody but high end geometric data crunchers are implementing the sacred geometry structure for compressibility/fidelity benefits. When your model has 10 billion vertices, and you have to quickly swap it from drive, to ram, to app, and store a hundred thousand years evolutionary algorithm permutations on it, it begs solutions from the primordial ooze... lol For games I see this eventually leading to faster delivery of mesh on all fronts, network, local, graphics processing, etc, but even more interestingly an automatic LOD that works more like reality does. As you get closer to something in scale more of the internal dodeca zones load in, being the golden measure it will all feel quite visually immersive and look real too.... Yes... my Monday coffee is kicking in lol! ? Sansar does have a nicer feel with the PBR, Id love to have that here some day, but they'd have to support legacy and new stuff, must be possible, no? Seems like theres new blood in SL or more fire, im always hearing about new features and the tons of projects going, seems they're on the upswing for evolution and modernization. Edit: A little more to the topic at hand, reducing bandwidth, why not include a larger default texture set in the viewer? right now theres only some normals, specs, and a two blanks AFAICT ...and with this larger built in set, give an li discount to mesh that use only those textures. Could curb a little bandwidth usage and cause some interesting creations to sprout up. Another thing is shaders, give us shaders, many shaders means less textures, at least far far more that can be done with less textures, and even infinite things with zero textures. Im currently grappling with terrain mesh and how to layer in the details I want, not having a shader to use multiple tiling textures that can be dispersed & blended by height or weight paint for instance, will cause me to increase my mesh layers, textures needed, and time needed to pull off a desired look. All that could be gone with allowing sets of 1024 images (with individual tileablility) baked into a singular texture atlas, and some creative shaders. Those atlases could also save some request calls & viewer strain at least, if not bandwidth.

Wow this is exciting! Another excellent idea in the perpetual evolution of SL, whats happened over at LL in recent years? I see a lot more lindens out and about, all sorts of awesome upgrades and enhancements in the works, greater community connection focus, and an overall a much more exciting progress oriented footing in the realms. ...And some thought Sansar would detract, I see it quite the opposite, there is a positive feedback loop that is giving extra energy and drive to both sides, and cross pollination of ideas/devs will continue to flow as well. This feature is so damn amazeballs tho!... i have used the Firestorm windlight enhancement for a long time, but this feature means everyone can have the immersive artistic impression the creator had in mind while constructing the experience zones. Environment is so essential in design, and now we can do this per parcel, per sim, per height zone! Not only that, but it looks nicer, smoother, and enhanced, that I was not expecting and is a great surprise! The only other possibility in addition to this cool stuff would be a more fine grained control yet, for instance, the basement in a building could use a different lighting scheme than upstairs or outside. That can really just be done with independent lighting setups, I know, but what if we could, say, set a different windlight inside the water on a mesh lake or pool? Or the different areas of a building etc. Not really needed, but im just throwing that out there as a future potential. Maybe this could be a new a prim-type that sets an area which can have its own windlight settings for anytime the camera is inside the zone, many games use that trick to simulate being underwater or inside some space, SL does that actually with the linden water based on height of water surface and camera position. As an aside... since that reminds me... SL has perfectly working Mirror system already too! The linden water is not actually transparent, its a mirror on the top and bottom of the surface showing a rendering of what is on the other side, you're not actually looking through it from above or below. This technique would be excellent for creating Occlusion Zones as I have mentioned elsewhere in the forums, these zones could be fully occluded (not loaded or rendered) but still have windows/vierws showing the outside/inside depending on where you're viewing from. It could be a window or even a huge screen backdrop, or even used to totally occlude a neighboring sim, yet still be able to see it on the horizon in the distance. lol damn im rambling again! ?

This vid is great on many accounts, you can refine your render quality, as well as speed up the process depending on whats needed for each render, tons of useful tips. GLHF! Why cant we post videos anymore?? https://www.youtube.com/embed/8gSyEpt4-60

yea, I would imagine its a very demanding task to make adjustments, and sort thru all the different things that could be done at any given time. At least it shows you're usually ahead of the curve on what to do next. Im surprised that would even sell, an ip address is not fixed unless someone pays extra, the overwhelming majority of people do not have a static ip, their ip changes all the time, their ISP is one of the few that can confirm who had what IP at what time. Any MP product trying to block people by IP is really going to have like 99% miss for their intended targets lol.

perhaps that was it, I did test both ways, letting the exporter finalize all the modifiers seemed to work alright, but it was inconsistent, a few times I lost half the vertices when importing but it seemed more related to having the front and back in the same location. Hahaa, well there ya go, I love learning new useful things! thanks for the pointers & excellent posts here in the forums.