Jump to content

Tree leaves


VirtualKitten
 Share

You are about to reply to a thread that has been inactive for 672 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I have been starting making my fist tree the hard way but am jumping away to leaves . I found this great tube on creating trees 

it said in the comments a better way is to use  displaced sphere (using a noise texture) and add a particle system with the leaf as the render object, and set to 'volume' What exactly and how is this done please and will this work in second life or create so much stuff it wont import?

  • Haha 1
Link to comment
Share on other sites

We do not support displacement maps in SL. So no that will not work I'm afraid. As you predicted you'd have to convert the resulting displacement mesh into a high poly mesh that would not be viable in SL.

  • Like 1
Link to comment
Share on other sites

The basic principle of using a particle system to distribute leaf cards across a surface does work, but depending on the software you're using it can be a bit of a pain to set up and there are probably easier ways to achieve the same results regardless of what app you're working in.

@VirtualKitten Since you're playing with trees here's a handy link explaining how to make trees like this

Airborn - Trees

0909_500.jpg

 

  • Like 1
Link to comment
Share on other sites

Hi Beq, Fluffy. Thank you both of you that is very interesting, so you need this NormalThief  script in Maya and in blender  Sapling Gen Add . will this work with 2.93 on to create spherical normals?

Will this work In Secondlife as am aware Blender is very advanced and might create massive li count for your model which most of us would like to avoid. Is this the best approach to create wavy leaves  that blow in the wind too?

Am still getting oddly high Li  count on my tree trunk which costs 13L to upload but creates 390li  after a time consuming amount of work reducing vertices edge density from twenty to ten. Would a similar normals use approach lower this tree trunk to a sensible amount as arrived at by Aquila  39 Li for a similar model derived in same way.  Is this the missing link? I am struggling to get this Li down starting with around 400 Li with  my process to reduce loop vertex creating odd number of vertices which created more faces vertex and nodes. The odd thing about this was i managed to work through the model where I had created this problem to add vertices myself instead of using blenders  Bridge End Loops this removed this problem but created 500li. Now this was completely weird as my model had less triangles.b5995ccba35429fec9fb7a299f188b70.png
 

I did play around with normals on it turning it a lovely blue color but didn't understand what it was doing .

Edited by VirtualKitten
Link to comment
Share on other sites

3 hours ago, VirtualKitten said:

Am still getting oddly high Li  count on my tree trunk which costs 13L to upload but creates 390li 

Not odd at all !

I have already explained to you more than once that to reduce the LI cost first work on reducing the Vertex/triangle count to a minimum.

We reduced the number of vertices in the edge rings (loops) from the initial 20 to 10. This was OK for the tree trunk and main branches but I also said that we don't need that many vertices in the edge loops for the many smaller branches. We could reduce the loops for these to 5 using the same methods as we did for reducing the vertices count for the trunk and larger branches. Then set all to smooth shading.  Did you do this reduction for the little branches? Looking at your tri count the answer is no!

I also explained (again more than once) that for such a large model (bounding box dimensions of x=57,  y=36 and z=56)  uploading it as a single object would result in a very high Li cost. To reduce the LI cost we had two choices:   One,  it would need to be separated into a collection of smaller objects  before uploading or  Two,  we could try setting it to use Animesh because as far as I know size does not matter when calculating the LI of an animesh and that also the maths used,    triangle count/1000 * 1.5 + 15    should result in quite a low LI . I also mentioned that if we needed collision surfaces for the animesh tree then that would have to be a separate object, set to 100% transparent and then linked to it when rezzed inworld.

I told you that I would take the animesh route (result: animesh tree + linked Physics model LI=39) and suggested you go to the Beta grid and do some test uploads with the tree separated into smaller objects and see how that effects the LI costs.  A week later did you do those test uploads? Again the answer is no. (result tree (BB size, 57 x 36 x 56 with 4799 triangles) LI = 400. 

I really don't see how I can help you any more on this project.

 

Edited by Aquila Kytori
  • Like 1
  • Sad 1
Link to comment
Share on other sites

Well i dropped it even more low poly and four nodes in each loops  in  major branch his reduced vertices etc. It still made a whopping LI 239 I presume Aquila has some secret to get his down to 39 LI. Aquila kindly went straight on to Animesh which is not needed at this stage as the leaves need making first which I am exploring on this post using normal . We really don't need branches moving as this is an oak tree and rather needs leaves moving.  I am still not understanding why he can get 39 LI form a model with ten  or five as with four mine is still higher significantly. I am grateful of any breadcrumbs as I am learning still and I value all contributions from Aquila and everyone as the subject on leaves is so huge i don't want to start out on the wrong or written for Unreal or a different engine other than Secondlife.

 21e72cc1877f46934995976dca7da192.png

 

fd1a6db7c578dfb3819eba3bacc9c771.png

 

Edited by VirtualKitten
Link to comment
Share on other sites

Hi all  well I reduced the ring count to four and still get this deformed shape tree which is no good . This clearly is not the answer to LI I believe Aquila is doing something to get LI down which Aquila wont share . Am at a loss to know why this is still 269 LI? If this is a secret I think developers will be leaving. I note the original leaves  person was concerned this information they had was being removed and put it on their own server. 

48a5fb3760c366115fd725dd5e49075b.png

 

In fact first tree with textures at my house was 181LI be7b8b7b5cc06120c109f2de3e3d74d3.png

 

In fact Aquila kindly used one of my first made trees to put the Animesh in which is missing parts as can be seen. There fore i cant test it in beta testing area . I have made no progress getting this lower by reducing poly loops vertext please share the secret of your 39 LI from 180 LI . Is it the missing parts ?
88dc6c1a76d2a474c53234444c9fc321.png

Edited by VirtualKitten
links didn't get converted to images
Link to comment
Share on other sites

Further more none of it still fits my models . The problem is something to do with links of two branches  as these cannot be sustained in LSL larger than 80 links due to the distance . This results in one branch being off as when the framework is exported from second life it does not hold its grid position in blender and centers at the cursor and has to be moved manuallyinto position Am becoming frustrated as I can see no solution for this only  exporting a wedge of its distance wrong from second life how far it is off . I now have decide which model to change as the low polly one i not much better

209896414256aa0beb56bbe75c85c063.png

Link to comment
Share on other sites

2 hours ago, Aquila Kytori said:

also explained (again more than once) that for such a large model (bounding box dimensions of x=57,  y=36 and z=56)  uploading it as a single object would result in a very high Li cost. To reduce the LI cost we had two choices:   One,  it would need to be separated into a collection of smaller objects  before uploading or  Two,  we could try setting it to use Animesh because as far as I know size does not matter when calculating the LI of an animesh and that also the maths used,    triangle count/1000 * 1.5 + 15    should result in quite a low LI . I also mentioned that if we needed collision surfaces for the animesh tree then that would have to be a separate object, set to 100% transparent and then linked to it when rezzed inworld.

I told you that I would take the animesh route (result: animesh tree + linked Physics model LI=39) and suggested you go to the Beta grid and do some test uploads with the tree separated into smaller objects and see how that effects the LI costs.

I am not even going to ask which part of this you didn't understand because :

57 minutes ago, VirtualKitten said:

 I believe Aquila is doing something to get LI down which Aquila wont share

 

 I now give up !

  • Like 3
  • Sad 1
Link to comment
Share on other sites

2 hours ago, VirtualKitten said:

I am still not understanding why he can get 39 LI form a model with ten  or five as with four mine is still higher significantly.

 21e72cc1877f46934995976dca7da192.png

FIrst, it would be really nice if you deleted the video in your original post. It's all about making scenes for still photos and there is nothing it it that is useful for game/virtual reality assets.

If you followed the video there's likely to be a large number of hidden triangles inside the trunk, how many depends on how well the remeshing step went. First step is of course to check if there are any of those and if there are, delete them.

Next step is to delete all those little twigs at the end of the branches. They add a lot of tris and they won't be visible once you've added the foliage.

Step 3: remove even more edge loops towards the top of the trunk and along the branches. Remember, the higher up in the tree, the less details are needed, partly because those parts are further away from the camera position, partly because those parts are more obscured by the leaves. Look at the top of the trunk from the highest branch and upwards for example. You have seven edge loops along that part of the trunk and you only really need two at most, possibly only one or none.

Step 4: Add some extra vertices along the lower three edge loops (including the bottom of the trunk) for the high LoD model only. Yes, this will of course increase the complexity but not that much and it's worth it since this is the most visible and noticeable part of the tree.

My rough guesstimate is that you shold aim for around 500 tris for a trunk like this. It can be done at around 300 but we're on the advanced manual there and 500 is fine for the trunk for a "feature tree" - that is one you don't have many copies of in the sim.

Edited by ChinRey
Link to comment
Share on other sites

Well I made it fit mine and had to move the limbs to make it fit . I just need to reduce the 330 LI.

 I like the shape of it now but its at 330 to high i dont know what Aquila did to get it lower , Aquila wont help let the secret out

its the 10 vertices model he said i should use  not 20:

7a0770623defac23cdc6c66fe73c3056.png

 

It fits but for some reason the texture does not come out the same idk

 c0edb36dca8d22f4c2a696df0a0e744e.png

 

{{Hugs}} D

Edited by VirtualKitten
Link to comment
Share on other sites

1 hour ago, ChinRey said:

Next step is to delete all those little twigs at the end of the branches. They add a lot of tris and they won't be visible once you've added the foliage.

Step 3: remove even more edge loops towards the top of the trunk and along the branches. Remember, the higher up in the tree, the less details are needed, partly because those parts are further away from the camera position, partly because those parts are more obscured by the leaves. Look at the top of the trunk from the highest branch and upwards for example. You have seven edge loops along that part of the trunk and you only really need two at most, possibly only one or none.

Step 4: Add some extra vertices along the lower three edge loops (including the bottom of the trunk) for the high LoD model only. Yes, this will of course increase the complexity but not that much and it's worth it since this is the most visible and noticeable part of the tree.

 

The twigs are in the original model and not much I think Aquila now says head for 5 vectors in loops not 10 to upload which Aquila said in first place this took me 2 days to complete the down grade to 10  in the loops  because of the fact I had extra vertices . I expect changing it to five will be complete hassle for not much gain either as I made it 4 and still got high LOD.

Aquila kindly got a version in at 29Li which is 10 times lower which is ridiculous and wont say how it was achieved. The Animesh although interesting is not going to change LI however the edge loops are essential if i do go that route. The kindly supplied Animesh didn't work as certain twigs where not in groups and left behind  so 1. it was not useable as Animesh in it failed to move all groups . 2. it was not the current model but an old one Aquila had .

Further to Animesh I only need leaves moving which I am trying to be advised the best ones to get into Second life the video was good but another webpage gave a version how to create them with normals which I am not totally familiar with  i don't know if this is for Unreal Engine which I am unfamiliar with.
 tutorial_01.png 

 

Link to comment
Share on other sites

9 hours ago, VirtualKitten said:

This clearly is not the answer to LI I believe Aquila is doing something to get LI down which Aquila wont share

Aquila told you what to try: make it Animesh. Because Animesh objects calculate Land Impact differently.

But you can't upload an object in Animesh form! You have to upload it as ordinary mesh, then rez it, then use SL's Edit panel (Features sub-tab) to turn on the Animesh checkmark.

That means you can't tell what the Animesh version's LI will be while you're uploading. You have to actually *do* the upload (and use the Preview Grid, it has free uploads!), turn on the Animesh option and see what happens. And understand that even though this can't reduce your upload cost, it will still affect how much LI the object uses up in the sim, and that's still good.

Edited by Quarrel Kukulcan
Link to comment
Share on other sites

@virtual kitten  Is the tree too large? What is the size you are uploading at? 5m tree or 30m?

@ChinReyIn SL, I can have a 4800 tri model (if I wanted to be sloppy) and if it is 1m or less than it is fine and if I do diligent LOD models I can even get it to be 0.5LI in the end.

But yeah, take a 320 tri WALL PIECE at 4m or 5m suddenly we're jumping up to 5LI too.. Make that same 320 tri Wall piece (that is a low poly model count ffs) up to 20m and watch it balloon to 50 LI!

Could you give me your opinion and advice on this, and is it related to ops problem? It's the same reason I wouldn't upload 'background city buildings' because even if they are low tri count, modestly sized textures (to account for viewing far off), and even set them to a conservative 30m high, their LI balloons to crazy levels...

 

Edited by entity0x
Link to comment
Share on other sites

Hi Quarrel

12 hours ago, Quarrel Kukulcan said:

But you can't upload an object in Animesh form! You have to upload it as ordinary mesh,

This is not what I was testing/meant.  :)

My idea was if we  made it as a proper animesh object it would reduce the LI a lot because of the way Animesh accounting is done. Size not acounted for and  LI = n/1000 * 1.5 + 15. Where n is the number of tris in the object.

After optimising the tree and doing a test upload as an ordinary mesh object to get a standard LI cost I then went back to Blender and bound the tree to an Avastar Animesh rig, weighting all the vertices to mPelvis. Then exported using Avastar's Collada exporter,  imported into SL and then set it to use the Animesh option in the build floater.

Simply setting the ordinary tree mesh object to use Animesh in the Features panel of the build floater had the effect of increasing the the LI.  (+15 for animesh)

A few screenshots ............

First the standard tree mesh object  (LI =173 ) :

1-min(2).thumb.png.19ac4c2cb2be70e61b50f03dfd019fed.png

 

Next the same tree model with Animesh option enabled (LI = 188) :

2-min.thumb.png.7d7ff86b5cde630c27011c87c9f1f269.png

 

And now the same model but rigged and weighted to Avastar's Animesh rig,  mPelvis bone but without the Animesh option enabled.  LI = 168) :

4a-min.thumb.png.bf1146ace4c5ec4fc34c097e475e9f39.png

 

And finally the rigged tree with the Animesh option enabled. ( LI = 19 ) :

4-min.thumb.png.6148b2cf41ab9c68117a64cc05151bd5.png

 

Because of the "strangeness" of animesh Physics this lower LI Animesh tree would (if VK needed collision surfaces) have to have a completely separate collision model (Visual + Physics) and be set to be transparent when linked to the tree. The tree objects Physics would then be set to Physics Shape Type: None.

 

entityOx, the size of the tree tree is approx. x57  y36  z56 m.

 

 

Edited by Aquila Kytori
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

You obviously have more knowledge from the formulas, for me it's just observation :D

For me I would expect such high LI count from the tree being 56m alone. SL doesn't seem to care much about tri counts or even 32 textures on the object, but only the size in game :/

That's why I'm piggybacking my question on your post, because the answer as to why will be similar

Edited by entity0x
  • Like 1
Link to comment
Share on other sites

40 minutes ago, entity0x said:

@virtual kitten  Is the tree too large? What is the size you are uploading at? 5m tree or 30m?

@ChinReyIn SL, I can have a 4800 tri model (if I wanted to be sloppy) and if it is 1m or less than it is fine and if I do diligent LOD models I can even get it to be 0.5LI in the end.

But yeah, take a 320 tri WALL PIECE at 4m or 5m suddenly we're jumping up to 5LI too.. Make that same 320 tri Wall piece (that is a low poly model count ffs) up to 20m and watch it balloon to 50 LI!

Could you give me your opinion and advice on this, and is it related to ops problem?

It is related to the op's problem because with meshes as big as that trunk the LOD models will hardly affect the land impact at all, only the full model really counts.

Download weight is calculated for each of the four LoD models separately according to their file sizes and then the four values are weighed towards each other according to how much view area each cover within a radius of slightly over 181 m (I can't remember the exact number) with Lod factor set to 1.

For a 57x36x56 m object, the high LoD model is supposed to be used all the way to 146 m view distance which means it covers most of that area. The low model isn't supposed to be used until the view distance is 584 m and the lowest 1169 m so they are way outside that c. 181 m "cutoff distance" and don't affect the calculated download weight at all. The mid model cover a little bit of ground but not much so it only has a very small impact on the downlaod weight.

If we go to the other extreme of size - 0.01x0.01x0.01 m - the calculated swap distances are 0.03, 0.12 and 0.23 m respectively. That means the lowest LoD model covers nearly all the stipulated view distance so it's the only one that really affects the download weight; you can add as many tris and vertices as you like to the high model and it hardly affects the LI at all.

 

  • Like 1
Link to comment
Share on other sites

Cool to get an experienced answer on this, now I can consider what might be happening based on this conversation and see why and wear bloat is happening in my bigger models too

Edited by entity0x
  • Like 1
Link to comment
Share on other sites

37 minutes ago, ChinRey said:

It is related to the op's problem because with meshes as big as that trunk the LOD models will hardly affect the land impact at all, only the full model really counts.

Download weight is calculated for each of the four LoD models separately according to their file sizes and then the four values are weighed towards each other according to how much view area each cover within a radius of slightly over 181 m (I can't remember the exact number) with Lod factor set to 1.

For a 57x36x56 m object, the high LoD model is supposed to be used all the way to 146 m view distance which means it covers most of that area. The low model isn't supposed to be used until the view distance is 584 m and the lowest 1169 m so they are way outside that c. 181 m "cutoff distance" and don't affect the calculated download weight at all. The mid model cover a little bit of ground but not much so it only has a very small impact on the downlaod weight.

If we go to the other extreme of size - 0.01x0.01x0.01 m - the calculated swap distances are 0.03, 0.12 and 0.23 m respectively. That means the lowest LoD model covers nearly all the stipulated view distance so it's the only one that really affects the download weight; you can add as many tris and vertices as you like to the high model and it hardly affects the LI at all.

 

Hi Chey the model is 60x42x48 metres

 

{{Hugs}} D

Link to comment
Share on other sites

43 minutes ago, VirtualKitten said:

Hi Chey the model is 60x42x48 metres

Oh kay. I got the numbers from one of Aquila's posts. I suppose you made some minor changes that affected the dimensions after that.

The difference is so small it has no significance though. To be exact 57x36x56 m gives a swap distance to mid at 146.068857 m, 60x42x48 at 145.945195 m. The swap distances to low and lowest are still way outside the 181-or-so m cutoff distance.

Edited by ChinRey
  • Like 1
Link to comment
Share on other sites

Hi ChinRey, entity ,

Yes  it has small size changes in BB I had to fit it to my model which I have now managed and  am asking  on three fronts about tree this was problematic as  blender dumped the .dae in centre of the model  and not at its actual reference location in LSL causing errors in model for location . I have created reference objects now and have a tree shape that fits . However 

1.  Li  which is high and the missing link kind  Aquila uses to get it to  10% reduction of what it was . How can it have huge li and cost 22 Lindens  upload fee? Is Secondlife creating bloat PHYSICS as a default physics modal which is responsible for this model LI rise? Aquila is brilliant at LOD Physics am guessing this might be how ?  

                                 I note Aquila's post above about Animesh which was excellent kind and helpful in respect to LI cost at 19LI even more reduction .  

2. Also my textures in blender 2.93 do not look the same in Secondlife using new texture shader. In addition having more than one shader seems to corrupts the blend file creating texture slots of same name . Is this fixed and noted in next release?

3) The model had a strange error message which I had never seen " Failed to unlink because you do not have object entry permissions on all parcels" if my root is on my families land why is this message there  as it is unlinking to my families land? It appeared for the first time yesterday. Surely my model is located at its root so why is this message occurring? 

Finally this thread is about leaves: 

1) what is the best method for making lag free wavy leaves . There are some good examples on Secondlife now . We have talked about some so far but the Physics route of creating these had one interesting post .  That thread was very interesting and clever but it only gave so much creating card displacement in a sphere it didn't really talk about animation. The inference I took from it as that physics(different physics)  in blender could help to do this in blender which requires a script NormalThief  to facilitate it in Maya.

Thanks D

Edited by VirtualKitten
Link to comment
Share on other sites

11 hours ago, Aquila Kytori said:

Because of the "strangeness" of animesh Physics this lower LI Animesh tree would (if VK needed collision surfaces) have to have a completely separate collision model (Visual = Physics) and be set to be transparent when linked to the tree. The tree objects Physics would then be set to Physics Shape Type: None.

 

Yes Aqulia but creating a separate physics model would not reference the Animesh current position for collision in Secondlife . You would require an Animesh physics for that which moved with the Animesh, the experts  have already discounted this in other posts in regard to linking two or more items to Animesh , when linked  the collision link sits at root so the collision model would be in wrong placement. It would somehow need to be done with physics ?

 

I am now wondering  if this LI  this bloat must be the lack of PHYSICS in importer which is substituting its own if you look at at Animesh  in world physics even though  didn't specify one it has a huge one generated PHYSICS by the importer . Do you have same thing  Aquila?

92468b929458df3bd989287b85e33567.png

Aquila Also I wonder if your experiancing wonderful low LI with the superbly written Avastar Export which is just to brilliant for words as I checked the Animesh check box on my in world tree and it made no difference to LI. Texture is still currupt on one of the limbs in second Life not shown in Blender.

I did a simple export check 
166ac49223cdb9bca4eafb0a1bf1f507.png

 

Edited by VirtualKitten
Link to comment
Share on other sites

What was the reason for making the tree animesh?    To test how the LI would be effected !

The other option was to cut the tree up into smaller parts with smaller BB's and test how this could be used to reduce the high LI cost. That was your job ! You miss out this important testing (learning) stage and then complain how the LI is still very high.............................

 

If you wanted the leaf billboards to be animated then I would guess the leaves bilboard model could be a separate animesh object and rigged accordingly to many more joints than this animesh tree that is only weighted to a single joint, mpelvis.   Again this would involve more testing.

 

More screenshots, this time of how the physics model (a much lower poly model than the actual tree) is uploaded separately and then linked to the animesh tree and a root prim that is set to Animesh :

Uploading the low poly Physics model, LI = 11 (same model used for both High LoD and Physics) :

2083258421_Tree_PHYSuploader-min.thumb.png.85ed7a3a9b831023aee7638b58cfc08a.png

 

The Animesh Tree and Tree Physics linked to a Root Prim to create a 3 object link-set and how after linking the Physics Shape Type is set for each object and how Root and Tree Physics will both be set to be 100% transparent. The Root prim is set to be Animated Mesh before linking. :

1822885896_Treelinked-min.thumb.png.df8182ab961301ef1566878574466829.png

Note that after linking, the Animash Tree and the Tree Physics objects will have to be aligned to with each other.

 

Viewed with Physics Shapes enabled :

1641340962_TreePhysicsShapes-min.thumb.png.9b9aca17fda40fe2bb7c902cb59ddacc.png

 

Bonus view :

1824467558_TreewithPhysicssittingavatar-min.thumb.png.9eb5b07cd290edaf000281d51197d9f5.png

 

 

Edited by Aquila Kytori
Link to comment
Share on other sites

OMG we are chopping more trees down . I took an axe to it but not sure how this will help as you suggested Animesh this will contain links and as previously said wont work as it only works with single mesh unless of course the leaves are separate mesh I now have 1 main tree and 10 twiglets.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 672 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...