[Opensim-users] some questions

[John Hopkin]

Lúthien Athariel wrote:

>Hi LaeMing
>
>thank you! This is very helpful.
>
>On 9-May-09, at 10:59 PM, LaeMi Wang wrote:
>
>> Hi Lúthien,
>> Trees in SL are a special object made from a simple algorithm and a  
>> special texture. I am not sure if these can be changed without  
>> altering the viewer.
>> Might be possible to change the texture.
>
>If that were possible, it would already be very useful (except for the  
>Laburnum which should have lots of flowers :).

I don't believe it is possible, but I'm not 100% certain of that.
Also, those "Linden" trees are client-side effects, so even if you
could make a change you'd see that new version in all regions, and
nobody else would see your texture unless they modded their viewer the
same.

>> However, trees can also be made out of clumps of sculpties or from  
>> flat prims with pictures of trees on them (3 such flat prims  
>> together, rotated at 120deg to eachother will give the tree some 3D  
>> body and doesn't look bad from mid-to-long distances. Custom trees  
>> like these won't bend in the wind though.
>
>I wonder if it is possible to import a tree built in Blender as such a  
>collection of sculpties: I will look at that (I have seen some info on  
>creating sculpties in Blender)

Depending on the shapes, you may well be able to do that, but
sculpties are pretty limited.  Most "sculpty" trees are actually a
combination of several sculpty prims for the trunk and major branches,
and standard prims with semi-transparent textures for the smaller
branches and foliage.

It's incorrect to say that prim trees cannot bend in the wind - simple
flat-prim trees, as LaeMing describes, can be constructed of "flexi"
prims that respond to wind movement.  As long as you get the prim
shape right, and use the same for all 3 (or 4 or however many) prims,
it will bend quite effectively.  I know, I've made some. ;-)

I'd recommend creating an OSGrid (or even SL) account and wandering
around in there to say what people have done - in general, and
specifically with trees.  I never cease to be stunned by the amount of
creativity and talent - not to mention technical expertise - that's
out there, and so much of it is freely available, even in SL.

>> Another viewer limitation - IIRC, SL has a limit of 8 active light  
>> sources (1 for sun/moon, 7 for prims), presumably because of  
>> limitations of graphics cards at the low end.
>
>that need not be a problem if I could, say, make the sun and/or moon  
>invisible and yet leave the lighting intact. If I then create a light  
>source and arrange things so per region that the sun- or moonlight  
>seems to originate from the direction of the new light source, that  
>might work - except that the light direction in the region where the  
>source resides would seem off.

You can't override that.  As I understand it, the limit of 8 is
imposed by software external to SL/OS, and the view reserves 2 for the
sun and moon (separate sources) and leaves the remaining 6 for prims.
If there are more light-emitting prims around you than 6, only the
nearest 6 to you will appear to emit light.

>> Sounds like a bug in stitching the regions together, likely when the  
>> two regions are being rendered at different LODs (Levels Of Detail).  
>> I suspect this because of the way the gaps disappear - if the  
>> regions suddenly start displaying the same LOD, this is what would  
>> be expected.
>
>Yes. I payed closer attention to this, and it looks as if it is indeed  
>connected with this level of detail.
>When I log in and there are these tears all over, it is also the case  
>that there is much less detail in the shape of the terrain. Then at a  
>given moment, the details will suddenly snap into place and the tears  
>also disappear.

You may be able to fix this by changing your graphics settings within
Hippo's "preferences".  Try bumping up mesh detail for terrain
(edit/preferences/graphics/custom).

>> LindenLabs (who's viewer Hippo is extended from) have been talking  
>> about  terrain-to-the-horizon for over a year. I am pretty sure it  
>> is possible to do  but would require some reworking of the viewer  
>> and possibly the server.
>> Normally the viewer is only plugged into its current sim and the 8  
>> adjacent  sims. To render further would require plugging into more  
>> sims at once, which  becomes an exponentially increasing load on  
>> both the viewer and the sims.
>> Rendering only terrain (and not objects) to the horizon is the  
>> compromise LL  is thinking of as it loads up the viewer more (but  
>> only if the user turns it on) and only minimally increases load on  
>> the sims (fetching height-maps, but not the rest of the sim contents).
>
>I would certainly be more than happy with the "just terrain" option,  
>because I do not intend to build structures that would be visible over  
>that distance.
>Maybe I'll  have a look at the code to figure out whether this is hard  
>to do - (I am a dev, though a java one - I never worked with dotnet).

I'm not a OS dev either, but like you I am a dev in other areas.  I
think you'd need to look at both the client (especially the client,
since that's doing the drawing) and the region (and asset?) servers
(to serve the textures and height-maps of distant regions).  I hope
you've got courage - I'm trembling just thinking about it!  ;-)  

Hope this helps - and bear in mind I'm by no means an expert.
-- 
John Hopkin