|
|
|
Just being able to link Linden trees would be a huge boon, but any customisation as well would be extremely welcome!
Custom Linden trees would enhance appearance of Second Life nature greatly. Many people like to create a garden on their land but it's difficult to make them look good with non-linden made vegetation. The built-in vegetation is mostly nice but there could be more different types of trees and bushes. Custom Linden plants would indeed open a fresh new business opportunities for many in SL.
I totally agree with the opinions above. It would be good news for all
in SL. So that you can see various vegetalization in SL, and we can make plants with more sofisticated form less problem with the number of prims. Sorry I don't really see much point to this? The optimisation would be extremely minimal unless you are using hundreds of trees and then it is still extremely, extremely minimal for a developed sim.
The only real benefit would be a prim reduction. SVC-350 describes the use of this in depth. It may even be a duplicate of sorts, but I see a huge use for custom linden plants.
This is directly related to the Speedtree issue, which is on the Render Roadmap. What I think would be most useful is a vegetation system that is optimised for games, that the users can manipulate and texture. This would be a fractal generation system pretty much. I can envision several fractal generator types for different types of plants. Tree generators is how most people in fact develop trees for Second Life, but we use them as textures rather than actual models. As the models are parametric and can be optimised greatly to small size, they are more efficient than the equivalent sculpty and billboard plants while at the same time being more realistic. Eata, even if you're just using one tree, the result would be much better looking than sculpted plants or crossed prims, and it would be cheap to implement.
In addition to the addition of new trees, I'd love to see some randomization applied so that all of the trees of the same type don't seem identical.
If parametrical, we could have a "randomize" value which could help a lot in generating random trees to make them not to be identical one to another... would be a really good thing, heh.
This is something that I would love to see, either implemented as suggested, or the parameters made made available in the create tree/grass function that is already in our build window. Being responsible for maintaining esthetics on two sims, I can attest to the potentially immense advantage of being able to eliminate the use of conventional prim plants altogether. Conventional prim plants have numerous disadvantages in the close quarters of our village sim, especially that of a tall tree using ENORMOUS (usually rectangular) transparent prims with the tree texture in the center. These transparent prims are constantly a source of interference for myself and the villagers when trying to edit or move an object about in the village, as one constantly fights the selection process, usually with the tree winning. I have had to retrieve objects several times for people when the object ends up behind a tree prim, or gets stuck to the tree itself on rez... a large number of these plants in fact make even the CTRL-ALT-T function, well, totally useless. Linden plants don't have such ridiculously large profiles, indeed they seem to have their own shape, nor do they interfere with transparency view. It has gotten to the point where I would ban large prim plants from the village... if there was a suitable replacement. VOTED!
Since the viewer code is open, and the code that renders LLPlants should be available, how feasible is it to submit a patch that allows the code described at https://wiki.secondlife.com/wiki/Custom_Linden_Plants
 through some sort of LSL bridge like what is used in the Emerald Viewer? I'm not clear on how Emerald can just up and modify LSL behavior, but perhaps we could look into this approach. 'Standard' viewers could see the 'billboard' texture of a custom tree, while those with the patch could at least have access to the Linden plant mechanism built into the viewer.
Maybe if enough 'billboard-ugly' plants spring up in the Linden viewer with people migrating to patched viewers, perhaps Linden might consider just implementing the damned patch and make 'Custom Linden Plants' an official spec. If this was implemented as a patch I would suggest an API like this.
1. Upload dummy sculpt texture that looks like a mushroom or something. Pick the UUID of that texture as the key to tell the viewer that this is a plant. So for the Emerald viewer, if you have a sculpted prim with exactly that sculpty UUID, you will see the particle system rendered as a Linden tree, and other viewers will see a mushroom that doesn't look totally out of place. There is also the '1 prim plant' texture. Slap the 'billboard' quarter of the LLPlant texture over it, and you are partway there since that is the effect of what a standard Linden plant does when not doing the full 'plant' thing. Unfortunately, I'm not clear on how to force the client to do a 'minimal' display of the plants. Ideally, in my mind, non-patched viewers would simply display what an LLPlant shows when it is using the 'billboard' quarter of the texture, but nothing more. The 'gold standard' in my mind would be using the Linden Oak Tree texture, having the 'real' one and the 'custom' version side by side, then having a patched & non-patched client zoom in on them both. The patched client would show no obvious difference between the two versions of the oak tree. The non-patched client would work as expected on the 'normal' tree, and would show the custom same as it would show the Linden Oak Tree being displayed in low-poly (the bill-board quarter), only showing that 'low poly' view all the way zoomed in.
I see 'indra/llxml/' has llxmltree.cpp in it, and more lltree*.* goodness can be found in '/indra/llprimitive/'. It is unfortunate, but I don't have the experience to even guess how to integrate that with 'Emerald LSL Bridge', or where to look for that bridge in the Emerald code. Hrm... 'a dummy scult texture'. Perhaps one of those 8-leaf 1-prim sculties? What happens in Emerald viewers when 'CONST KEY=CUSTPLANT' is used by someone, but it doesn't have the patched info attached to it? You would want to cover for the case when someone invokes key texture, perhaps as a normal sculpty or a surface texture, but doesn't supply the particle info required by a patched client. Hopefully, it would just show the sculpty and 'do nothing'. But that would be another test to ensure nothing breaks. Damn, I wish I had the technical skill to actually read the code and understand how LL renders trees, and perhaps see a way to patch custom access to the same code. Or that Linden would 'poop or get off the pot' with respect to Speedtree and/ or custom plants. Has anyone confirmed if Speedtree has been silently dropped off the roadmap? I don't think it's necessarily a good idea to have the non-custom viewer texture show it as a billboard. A billboard will protrude into the area around the plant, and won't look good. Also it wouldn't give the custom viewer a reliable cue, like a specific shape texture UUID would. Plus, the billboard would require two prims to look like the Linden tree at a distance. Better to have something that looks OK but maybe a bit incongruous so people would start asking "why are there all these giant mushrooms on your land?" and find out about the custom viewer that way.
The sculpt without a particle system would be rendered as the sculpt. It's the combination "uses the magic sculpt texture" and "contains a particle system" that would be the trigger. why not simply use that space for additional parameters that prims got ( I think someone the other day told me it's like 64KBytes or somthing) for the plant parameters letting the prim itself be whatever the creator makes it be. From what I udnerstand, clients already receive and ignore any extra info from that spare parameter area, so it would be perfectly backwards compatible, and clients that do know what to do with the data will recognize the prim as a plant from one specific hidden parameter and react accordingly.
I have been following these recent posts with interest as I spent a great deal of time last year working with this issue. At the time it looked like the Lindens might be be opening up editing custom plants soon. Then, and now, the parameters and UUid of the plant texture are contained in the tree and grass xml files. All LL's servers do is send out is type of plant, it's xyz location and size, and the texture requested by its UUID. The client viewer does the rest of the work constructing plant according the information contained in the xml files.
Aha! I altered the file- logged in- my sim was covered with red cactus in place of that bland Linden grass. most cool! Of course I was the only one who could see the cactus. Anyone else with an unaltered grass.xml would see the bland Linden grass. Oh well... -One can create some incredible beautiful and interesting plants (and environments with those plants) . SL would look a lot better if resident artists could create custom plants with speedtree and the grass engine.
-I made a tree that was several kilometers tall-fun! -I made a plant I called a Medusa Tree. If an avatar looked at it when closer than 30 meters the screen would dissolve into really neat crystal patterns and the computer would lock up completely.
- Tigro: that would be the preferred mechanism for Linden Lab to do it. What we're discussing here is how to do with without support from Linden Lab.
Peri: the viewer would have to limit the parameters fairly tightly, within the range of values currently in use. third-party viewers can't compile scripts that can edit those parameters, and/or can't have a GUI for editing them?
btw, the Medusa Tree, is it really an issue with the plant system itself and not somthing bigger in the underlying systems that can be abused thru other means as well?
Tigro: Additional parameters don't exist in the primitives until Linden Labs creates them and extends LSL and/or the viewer to edit them. Linden Lab has not done so. By using the particle system to contain the parameters it would be possible to experiment with custom Linden plants as attributes of prims without waiting for Linden Lab to get off the pot.
oh, I was under the impression that memory space for arbitrary parameters was already accessible, the clients just weren't doing anything with it (except a little with sculpties), I appologize if I was mistaken.
http://code.google.com/p/greenlifeemeraldviewer/wiki/LSLClientBridge
gives information about how the Emerald client bridge works, and yes, I'm talking about simply doing an end-run around Linden Lab so we have reasonable access to custom modify the LL Plant Code with a patch to a client that uses an LSLClientBridge as EMerald is doing.
1) It looks like you could use any prim, it just needs to have an LSL script that will broadcast to any listening bridges. If this thing works as intended, we will simply tell LSL not to draw the prim, but draw our custom plant instead. 2) All the glorious details of the broadcasting prim, including the UUID and settings are broadcast. Simply by letting my client perceive it, I know exactly how to duplicate your custom plant. So anyone wishing to sell their work needs to do so understanding they may as well publish the texture UID and parameters in 'cleartext', because everyone looking at that plant is doign precisely that anyway. 3) If you choose to use a mushroom sculpty, a flat sculpty, a flat prim or sphere, I think the only thing that matters is the ability of the LSLClientBridge to know with absolute certainly the UID of the broadcasting object, and that the UID is ONLY a 'thing', and not an avatar so as to avoid seed-sized 'hidden' avatars. This security needs to go all the way into the patch, so regardless of how the LSL chat is hacked, the patch only permits 'objects' to be replaced by LLPlant parameters. It is possible that LSL mechanics prevent this from being an issue, since LSL must be invoked within an object in-world or on a HUD, but it is wise to not presume anything. Could someone familiar with LSL look at the LSLClientBridge program if it does what I think it does? I'm only a beginning LSL scripter, and since the program fails to include useful comments, I'll need to slowly and painfully parse out the LSL to determine if it even does what I think it's doing. If the Bridge software provides the means, perhaps we could just arrange a 'dummy plant test': We have a prim with LSL that squawks to a listening bridge, "I'm a plant!" We would then need an attachment that listens to the channel and 'looks' for plants. It needs to be low lag. What initiates the process? Do plants broadcast their presence every so often? Or does the viewer announce, "I am looking for plants?" Do plants store a list of what clients have 'seen' them, periodically flushing the list? Is it better to make this an internal memory issue of the client to store announced plants in cache, the way textures are stored? Would this affect who initiates the 'plant handshake'? Alas, I'm not even close to knowing the answers to these things, but perhaps someone watching these comments would know. But without any patching to the client, we could work the chat and handshake issues out and test with dummy receiving code that the patch would process... if a patch existed. But that would bring us closer to the in-world side of the equation. As far as the 'code patch' side, we may have to find a sympathetic ear in the Emerald Code Crew. Hopefully what I've described even heads in the right direction, in spite of my incompetency to get it moving. I don't think any kind of direct scripted scheme like the Emerald LSL client bridge is even vaguely practical for this application. It has to scale to hundreds of prims per region, and work across multiple region boundaries. You have to be able to tag any prim in draw distance. You need to have trees show up when you cam over to a parcel half a sim away in a catty-corner sim. Chat just can't do that. Even having to have a running script in the prim is impractical. You need something that is inherent to the prim. Emerald already takes advantage of specially tagged texture UUIDs, to color people's nametags, so using the UUID of the sculpt texture is a perfect tag.
Excellent! Yeah, I was worried that the way I suggested would present far too much load.
So... someone creates a texture key and publishes it as a CONST. The key happens to be a sculpty map that looks like a mushroom. @Argent, would you happen to have a map in mind that you would release for this project? Your suggestion really does make more sense. I'm not certain a mushroom sculpty is the best way to go, but if we have this thing work, I'm not going to care because I'm not going to perceive it unless I have to use an unpatched client. I'm thinking of it in the way of "TEXTURE_DEFAULT, TEXTURE_BLANK, TEXTURE_TRANSPARENT" are used. Once the client 'sees' the trigger "TEXTURE_PLANT", in the sculpty portion of the map... what happens then? At THAT point is it feasible for a script inside the 'plant object' to tell the client parameters 'on request'? That hits back to the problem you wish to avoid, but at some point all that data we would prefer to not push from server to client needs to be communicated. The UUID of the sculpty map floats from server to client... does the name and description float in that one shot also? Can the info we need be compressed into that space? ideally the custom plant data would be transmuted in a way that doesn't affect noticeably the appearance of the prim in any way to allow creators to choose how to represent the the plant for people without the custom plant clients...there should be a way to steganograph the data into arbitrary prims in a standard way...
ok, I thought somthing, it still restricts things a bit, but just to sculpties with white (looking) tint, I'm not sure if it allows for enough memory for all plant parameters
all the regular prim parameters stay saved when switching from one prim type to another, including to sculpty, embed most of the data in the regular prim parameters, what will identify a prim as being a custom plant will be it being a sculpty, with color values above <1.0,1.0,1.0>, anything above that looks white, but the larger values can still be read by scripts, I imagine (and hope) they also reach the clients bigger than usual and just clip at white for rendering @tigro: you don't need to play games with illegal values that might not survive the LLSD compression. Just use the sculpt texture and the presence of a particle system as a cue.
@romaq: I already explained what happens then. The viewer looks at the particle system of the prim. If the particle system has (say) Alpha 0.05 (which is an invisible value, anything below 0.06 gets ignored) and a lifetime of 0.1s, it assumes the rest of the particle system actually contains parameters for the plant system and treats them as such. @Argent: My apologies, I didn't quite wrap my mind around it the first time.
So at this point, it's trivial to set up a test object that doesn't do anything but ignored particles? And what's the best way to translate the particle system to LLPlant? I know one item requested was the ability to have separate billboard, trunk and plant textures, but I would think keeping it consistent with LLPlants and the single texture used for particles would be best for the time being. So what's the best way to recreate a Linden Oak Tree using llParticleSystem values? And does anyone have an ideal 'Mushroom Sculpty' UUID of their own to offer in use for this project? In answer to Tigro's question about the "Medusa Tree". There seems to have been no bounds checking all along the line. The computer could only be rebooted by shutting off the power indicating that there was a serious splash of memory writing where it should not be. Speed tree took my bogus numbers and passed them to windows which then choked on them.
If I am following Argent's explanations correctly, there is still no way to directly transmit plant information parameters from a prim inworld to a viewer-client. The information would still have to in an xml file in the viewer to use to pass parameters to speed tree. Is this correct? @Peri: What I'm describing here is a way to implement passing the parameters from in-world to the client. The information would be stored in a particle system, so PSYS_SRC_TEXTURE would map to texture_id, PSYS_SRC_BURST_RADIUS to billboard_scale, and so on. There would be no new XML file in the client.
Bounds checking would have to be implemented in the code that translated the particle system to the tree system in the client. Perhaps one parameter would map to species_id so that if you specified a particle system only containing that parameter you'd end up with a clone of that tree... and other parameters would be applied as differences from that species... this would make it easier for people to develop trees. For example, specify a tree with a species_id matching eucalypt, but a different texture_id, would be an easy way to create a variant gum tree. @Romaq: to recreate a Linden Oak tree, you'd just provide a particle system with the Linden Oak species_id and nothing else. @Argent: What I had in mind is a 'map' of those parameters, and something by way of example. I believe what you have suggested is an excellent idea, I just need to wrap my mind around the specifics.
Hrm... I guess the best way to do it is to 'just do it'. As far as the Linden Oak species_id, the ability to ONLY pass a texture and a species ID would be fantastic in so many ways, and save so much time. But for the purpose of hammering out a spec, not so much. So here I will take the generation script from http://lslwiki.net/lslwiki/wakka.php?wakka=LibraryKeknehvParticles (gawdawful llparticlesystem mush removed... too ugly to let live) Gah... gotta head to work. I'll try to peal the XML specs from the oak tree, and then work through translating that XML to the above pattern, including the 'species ID'. Sorry folks, I have more time to play with it over the weekend. Here's a thought as a stop-gap.
Perhaps we could collect here various tree specs that could be cut&paste substituted for trees in trees.xml. These could then be integrated into third-party viewers like Emerald, somewhat like they do with the extra attachment points. After a suitable period of testing, LL could then integrate these extra tree types into the master trees.xml file, adding them for ALL users. Of course, this assumes that the server does not reject out-of-bounds tree settings, and the standard viewer's response to them would be something acceptable, such as giving the tree modulus the number of trees available in the standard trees.xml file. At the very least, these tree definitions could be used by photographers and machinamators to provide a new look, and if we have to skip the step of distributing them in a third-party viewer first, that would be fine. A good crop of possibles might give Linden Labs more impetus to put the additional ones out for everyone to see. (For that matter, maybe Imprudence , Emerald, or CoolViewer might even put in an interface to manipulate the parameters of the current trees live in the viewer, so that we could test things and see how they look, before cutting and pasting the output from the "assemble specification" button in here.) [An in-viewer particle system builder would not be taken amiss, either...] {I seriously need to learn to code, some time.}It's a good idea, TaraLi, as far as testing we can do hacking trees.xml for custom ideas we have. If anyone has some good sample trees.xml hacks and screenshots, let's have a look! I think it is a valid question if we actually could just tweak trees.xml, what can we get out of this that would make it worth the bother? And it's something we could do only by swapping trees.xml files.
Unfortunately, I don't have so much faith in Linden Labs moving in a timely matter on this issue. If LL were going to be more proactive on this issue over the two and a half years since Argent opened the topic, we would have seen more Linden involvement. It would appear we either make this a reality through the client Open Source or allow Custom Plants to silently drop, possibly forever, due to a presumed lack of interest. "If it is to be, it is up to me." - William H. Johnsen We have access to the client source, and we appear to have the means if we can interface triggered particle code parameters to the plant rendering system. We can do this, and having done it, we can offer people yet more incentive to just not bother with the 'official' viewer. Or Linden can actually do something like PRODUCE, but I don't think it likely at this stage. Anyway, I'll have time to really examine trees.xml and see my way to mesh the Oak Tree specs to Particle System specs... sorry about that mash of stuff, I just now removed it since the formatting was lost and I didn't do anything constructive with it at the time. This weekend I'll be able to focus on the XML and make an attempt to map it. I would not complain if someone ELSE were to jump the gun and do it in my place. Once we have the details worked out with a custom tree based on the sculpty prim UUID and the llparticlesystem interface, we can look at how to redirect particle rendering to the plant rendering system. And meanwhile, of course, hacking the trees.xml file gives people a sufficient head start on the fun until a patch can be cooked up to render it 'live'. Hrm... the temptation to do a 'seasonal' hack of the oak tree is pretty strong. This a shot with the Emerald viewer with a normal Tree.xml
This is with the Linden Viewer with a hacked tree xml
I think that it is a great idea to start designing speedtree plants by what ever means. These are the parameters for the warped oak tree in the attached images
<tree name="Oak" species_id="1" texture_id="bca09883-372c-176a-376c-7b9617719ed8" droop="44.0" twist="11.0" branches="5.0" depth="3" scale_step="0.7" trunk_depth="0" branch_length="3.5" trunk_length="3" leaf_scale="7.0" billboard_scale="10.25" billboard_ratio="1.0" trunk_aspect="0.15" branch_aspect="0.07" leaf_rotate="0.0" noise_mag="1.2" noise_scale="4.0" taper="0.3" repeat_z="4" /> Enjoy! Could you try those images in daylight? I can hardly see them even on my good monitor.
PS: these are not Speedtree trees, these are Linden trees. Speedtree is a different product that LL didn't actually incorporate. Normal Oak with Emerald Viewer
Sorry about the night shots It was very late here in RL  Altered Oak with 2nd life viewer. I have changed the code a bit it is now-
<tree name="Oak" species_id="1" texture_id="bca09883-372c-176a-376c-7b9617719ed8" droop="44" twist="11" branches="5" depth="3" scale_step="0.7" trunk_depth="0" branch_length="3.5" trunk_length="7" leaf_scale="7.0" billboard_scale="14.2" billboard_ratio="1.0" trunk_aspect="0.15" branch_aspect="0.07" leaf_rotate="0.0" noise_mag="1.2" noise_scale="4.0" taper="0.5" repeat_z="4" /> Thanks, Peri! That's exactly the kind of posting I was hoping for!
I inserted said tree into my trees.xml, replacing the original Oak line, and tried it out in both Emerald and Imprudence. That's a good tree to test with, as it's commonly found around SL in the center of newbie money trees. Admitted, that design would make it very hard for newbies to find the money in the tree, but it does look pretty good! I can't wait to see what others come up with! I need to play with this now myself! Happy to be of help
A couple of other experiments that I found useful: Take the texture id of one plant and insert it in all of them. It is not only strange looking in some cases, but it will give you some idea of what the other parameters do. Use llSetTexture to rez the Linden textures on the flat surface of prim. Very instructive to see what they used Having gotten fired up by the all interest in this topic, I have rebuilt my experimental garden. It has all of the linden plants(I think). I found it useful to have the plants in a somewhat isolated environment when I was experimenting with moding trees.xml The slural:
http://slurl.com/secondlife/Afar/95/99/2224/?title=The%20Experimental%20Garden You will also find a complete selection of ground cover on the ground level enjoy Excellent! A really nice way of handling them! It really does help to be sure what you're seeing.
Now, I'm thinking a spinner, maybe, to let you select which tree you want to replace, and another to select what new tree to replace it with, and it'll pop out the line to C&P into the file for you. I wonder if the textures might be available somewhere full-permission, so we can edit them to play with them a bit - maybe just things as simple as turning the leaves blue or yellow might be interesting. I think someone needs to tag Torley with this - maybe he can stir up the pot a bit, as he does so much SL photography as it is... Copying and pasting lines into a file is OK for playing with the idea, but to make it useful for building it has to be something that's driven by the presence of tagged prims in-world.
I'm looking for a phased approach here - we make content, Emerald or Imprudence makes making content easier - but we're limited to the 21 trees in the trees.xml file and 6 grasses in the grass.xml file, then Linden Labs looks on it, maybe Torley sees pics taken with it, and encourages one of the devs to take a look. They decide to expand the trees.xml and grass.xml files, and while the dev is looking at it, decides he can throw in some of our other wish list.
So, yes - the end result hopefully IS new trees that are one prim. With random variability, and such. But it'll take a little time to get the bribe of pre-made community content ready. That's what I'm looking at here. I had intended to create a 'conversion table' that mapped trees.xml fields to Particle System fields set to the 'out of bounds' values Argent suggested. This would prevent custom plant data from displaying on any standard client while allowing the values we want to be fed to a custom plant patched client.
Unfortunately, my wife's father died, so I'm borrowing Internet to check email and for any fires. We'll be traveling and recovering this coming weekend, so it will be the weekend after next before I can produce such a table for testing.It is desirable to read both the trees.xml and grass.xml files to verify the following: 1) The named fields are the same, or if there is a difference, what the explicit differences are. As I recall, all the GUID's for plants and trees are full perm, but we can't 'download' them to work with them. But we could either use GLIntercept to extract the public Linen textures out of the client, look up the GUID's in the program directory and convert the .j2c files to .PNG, or simply ask Linden to very kindly please post the plant textures and the GUID's in the WIKI. At some point I can look up and convert the plants from .j2c, I think, and publish them. But it won't be next weekend. It would be great to have Linden actually move on custom plants. I don't expect to see that happen, but it would be wonderful. But until we see clear evidence Linden takes custom plants seriously, we either create the patch that makes it happen or do without. Doing without kinda sucks and has not made anything happen for the last three years on this. Argent- I could not agree with you more. Tagging a prim to provide a conditional jump point to custom code to feed custom parameters into the plant rezzing code is the way to go given that LL will do nothing with the server code. I have been looking at the viewer LL plant code and the functions that might be used to provide a cutout. My feeling is that it will take a programmer who is very familiar with the core code and is willing to spend a lot of time to implement your vision. It is a problem similar in compexety to creating a legal or illegal copybot viewer without the incentive to steal stuff... but,hey, you can look at some really neat plants. I think TaraLi may be right that to create some great designs that can be viewed by moding trees.xml might just spur some coder into saying, " I want everybody to see some really neat plants!"
TaraLi and Romaq- The following code will rez Linden's plant textures on a prim. The number in quotes is is the UUID or GUID? from the texture ID in trees.xml. This one will rez Tropical Plant 1. For the others, simply substitute the number from the other plants. It takes a bit of photoshop skill from there. If you need further help, please feel free to contact me in world. Romaq- sorry about you and your wife's loss. It is not an easy thing to lose a parent. default } |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Custom "Linden Plants"
https://wiki.secondlife.com/wiki/Custom_Linden_Plants