VirtualKitten Posted April 26, 2022 Share Posted April 26, 2022 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? 1 Link to comment Share on other sites More sharing options...
Beq Janus Posted April 26, 2022 Share Posted April 26, 2022 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. 1 Link to comment Share on other sites More sharing options...
Fluffy Sharkfin Posted April 27, 2022 Share Posted April 27, 2022 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 1 Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 27, 2022 Author Share Posted April 27, 2022 (edited) 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. I did play around with normals on it turning it a lovely blue color but didn't understand what it was doing . Edited April 27, 2022 by VirtualKitten Link to comment Share on other sites More sharing options...
Aquila Kytori Posted April 27, 2022 Share Posted April 27, 2022 (edited) 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 April 27, 2022 by Aquila Kytori 1 1 Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 27, 2022 Author Share Posted April 27, 2022 (edited) 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. Edited April 27, 2022 by VirtualKitten Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 27, 2022 Author Share Posted April 27, 2022 (edited) 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. In fact first tree with textures at my house was 181LI 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 ? Edited April 27, 2022 by VirtualKitten links didn't get converted to images Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 27, 2022 Author Share Posted April 27, 2022 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 Link to comment Share on other sites More sharing options...
Aquila Kytori Posted April 27, 2022 Share Posted April 27, 2022 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 ! 3 1 Link to comment Share on other sites More sharing options...
ChinRey Posted April 27, 2022 Share Posted April 27, 2022 (edited) 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. 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 April 27, 2022 by ChinRey Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 27, 2022 Author Share Posted April 27, 2022 (edited) 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: It fits but for some reason the texture does not come out the same idk {{Hugs}} D Edited April 27, 2022 by VirtualKitten Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 27, 2022 Author Share Posted April 27, 2022 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. Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 27, 2022 Author Share Posted April 27, 2022 (edited) I also think the shading in 2.93 is messed up if you have two master shaders it goes silly renaming both color slots the same name is this a known bug ? Edited April 27, 2022 by VirtualKitten Link to comment Share on other sites More sharing options...
Quarrel Kukulcan Posted April 27, 2022 Share Posted April 27, 2022 (edited) 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 April 27, 2022 by Quarrel Kukulcan Link to comment Share on other sites More sharing options...
Codex Alpha Posted April 27, 2022 Share Posted April 27, 2022 (edited) @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 April 27, 2022 by entity0x Link to comment Share on other sites More sharing options...
Aquila Kytori Posted April 27, 2022 Share Posted April 27, 2022 (edited) 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 ) : Next the same tree model with Animesh option enabled (LI = 188) : And now the same model but rigged and weighted to Avastar's Animesh rig, mPelvis bone but without the Animesh option enabled. LI = 168) : And finally the rigged tree with the Animesh option enabled. ( LI = 19 ) : 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 April 28, 2022 by Aquila Kytori 1 1 Link to comment Share on other sites More sharing options...
Codex Alpha Posted April 27, 2022 Share Posted April 27, 2022 (edited) You obviously have more knowledge from the formulas, for me it's just observation 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 April 27, 2022 by entity0x 1 Link to comment Share on other sites More sharing options...
ChinRey Posted April 27, 2022 Share Posted April 27, 2022 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. 1 Link to comment Share on other sites More sharing options...
Codex Alpha Posted April 27, 2022 Share Posted April 27, 2022 (edited) 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 April 28, 2022 by entity0x 1 Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 27, 2022 Author Share Posted April 27, 2022 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 More sharing options...
ChinRey Posted April 27, 2022 Share Posted April 27, 2022 (edited) 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 April 27, 2022 by ChinRey 1 Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 28, 2022 Author Share Posted April 28, 2022 (edited) 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 April 28, 2022 by VirtualKitten Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 28, 2022 Author Share Posted April 28, 2022 (edited) 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? 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 Edited April 28, 2022 by VirtualKitten Link to comment Share on other sites More sharing options...
Aquila Kytori Posted April 28, 2022 Share Posted April 28, 2022 (edited) 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) : 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. : 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 : Bonus view : Edited April 28, 2022 by Aquila Kytori Link to comment Share on other sites More sharing options...
VirtualKitten Posted April 28, 2022 Author Share Posted April 28, 2022 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 More sharing options...
Recommended Posts
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