|
|
|
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.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Custom "Linden Plants"
https://wiki.secondlife.com/wiki/Custom_Linden_Plants