[sldev] What's so special about grass?

Anna Gulaev annagulaev at gmail.com
Fri Feb 15 17:28:36 PST 2008


On 2/13/08, Dave Parks wrote:
>
> Grass definitely ignores the INVISIBLE flag, so you'll need to add a
> check for it in LLVOGrass.


rebuildGeom is not being called for any spacial group that contains any
drawable of render type RENDER_TYPE_GRASS. Backing further up the pipeline,
grass objects do have a drawable, are being found by the visual  mute
filter, are being flagged (not using the  INVISIBLE flag), are being put in
the priority rebuild queue, and are being found there. Someplace between
there and rebuildGeom the pipeline differs for grass and all other objects.

Simply not calling plantBlades does not un-render grass once its been
rendered. Exiting updateDrawableGeom for grass objects with status TRUE,
every time it is called for grass, will cause grass to not be rendered.
Doing so once it's been rendered does not result in it beig un-rendered.
Setting the drawable's state to BUILT does not work. Setting it to
REBUILD_ALL does not work. Returning status FALSE does not work. Yes, at
this stage I am just making guesses. I have no clue how to un-render grass.

Argent Stonecutter wrote:
> > On 2008-02-13, at 02:34, Anna Gulaev wrote:
> >> I don't seem to be able to keep grass from rendering using the same
> >> mechanism that I use for everything else. I removed the RenderType
> >> check (which did include grass) and I can then visually mute
> >> everyting--prims, ground, sky, trees, you name it--except grass. Is
> >> grass not in the global object list? Does it not generate object
> >> updates?
> >
> > Why not look at the code that "Client->Rendering->Types->[ ]Grass"
> > uses when you uncheck it?


That sets a flag that prevents any grass from being rendered. That's easy.
Deciding on the object level seems to be tougher.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080215/1d8a3f2f/attachment.htm


More information about the SLDev mailing list