Dynamic plants

[Ricky Curtice]

In ancient days we used the simplistic Linden plants.  The alternative was prim plants - not any better.  The sculpt plants, and since a while, mesh plants. At each stage the download size increased on a nonlinear curve - as did the quality, assuming a talented builder.

Also in the deep past there were thoughts about incorporating a dynamic tree generator, a la SpeedTree. From what I've read LL had purchased a license for it.  From a technical standpoint I'd love such a system: back to small descriptive assets to download and the ability to dynamically create/adjust LODs.

I suspect there was a few roadblocks, some of which could be:

* Creator outrage - taking away jobs, etc. Same outrage at the addition of sculpts and mesh.  Just remember that just like torturing a prim into exactly the shape you need, adjusting all the variables into the tree you want would still take time and skill. Not to mention all the texture work!

* Open source viewer development - if the tree generator is closed-source and expensive, like SpeedTree, what would be a fallback for TPVs that don't have the resources to license it?

* Developer time - I don't know what other projects are much further up the pipeline.

Questions to be resolved:

What other problems did I miss?

Are there solutions to the problems, and what compromises do those entail?

Is there a better solution, or set of solutions, to the core problem of trying to reduce server and network loads while increasing the quality of plant-forms?

Thoughts?

Ricky C, aka Cron Stardust

[Henri Beauchamp]

I suppose there are quite a few pieces of Open Source code out there
that could be a good base for an in-viewer procedural tree generator
that would take parameters from an asset (inventory or new type of
tree object).

A few minutes of search on the web lead me there:
https://github.com/jarikomppa/proctree
which should prove easy enough to adapt and embed into the viewer,
and which should be speedy enough to generate trees as the asset is
decoded (the resulting mesh of course going to be cached in the
viewer for fast rendering).

Obviously the result would not be as nice as what you would get with
hand-designed mesh trees, but still much better than Linden trees.

As an intermediate step and proof of concept, you could even make
it so that the Linden trees are replaced (viewer side) with trees
generated by this algorithm, each Linden tree having a different,
pre-determined set of input parameters for the procedural tree
generator.

Henri.

[Tara Li]

If you look at Linden Plants, there's parameters in one of the INI files that gives L-system style parameters for it.  However, there was no randomization introduced, so each Linden Tree or Linden Grass looked exactly the same.

Several people experimented with modifying those parameters to create other Linden Trees, but nothing really came of it - since you had to have those parameters manually entered into the INI file.  (Yeah, it's trees.xml)

Digging around, looks like someone took one of my rants and actually added it to the Linden Wiki - http://wiki.secondlife.com/wiki/Custom_Linden_Plants - or maybe I was inspired by their rant - it's been a long time ago.  But this is definitely something that would be rather easy to implement, I'm fairly sure.  Admitted, I am *not* a C/C++ programmer, so I am not the one to do it, but I can easily see the pseudo-code for it.

--
Archives of earlier incarnations of this list are at https://list-archives.secondlife.com
---
You received this message because you are subscribed to the Google Groups "opensource-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensource-de...@lists.secondlife.com.
To view this discussion on the web visit https://groups.google.com/a/lists.secondlife.com/d/msgid/opensource-dev/f0f794de-1c70-40c2-a14e-8fe458897b68%40lists.secondlife.com.