Aquila Kytori

To see how faces only have one side work in Blender with Backface Culling enabled. 1: Change Viewport Shading to Solid. 2: Open the Shading drop-down and enable Backface Culling

If you are using Blenders Particle system to position, orientate and scale your twig image planes then you will probably run into a few problems like : 1: end up with quite a high number of vertices. 2: end up with a lot of twigs/branches to close to or passing through the platforms and walkways. 3: ............. I would suggest that you go back to your reference tree and see how the twigs/branch billboards are made and positioned. ( Billboards are images on planes. ) Instead of using particles and converting them to mesh start by carefully creating/finding a good image to use on the billboards then create a billboard object of 4 planes in a form like in the image below: Don't forget to check the face normal orientation on this model before you start making copies ! 🙂 Then duplicate the original billboard model and manually position the copies (for variation with different rotations and scales) around the tree so that they will avoid all the platforms and walkways: When finished select groups of the billboard models and join them to be a single object with Ctrl J. Note: As your tree is so large it is not images of twigs with a few leaves that you should be using in the billboards but images of whole branches with hundreds of leaves. Do a quick test upload before starting to position all the billboards to check that the scale of the leaves are approximately correct.

Do you have Material Properties > Viewport Display > Blend Mode > Alpha Clip selected? Example for a texture that already has a fully transparent background :

For such a large object the Medium LoD will perhaps effect the Download cost a little but the Low and Lowest LoD's will have no effect on the Download cost at all ! Can I ask you to re- read Chinrey's reply to your question earlier in this thread red and bolding is mine : I just did a quick test................. With default auto generated lower LoDs the Download cost is 167 With the 3 lower LoDs manually set to their minimum values the Download cost is still 167 : And with the Lower Lods all set to use the High LoD model the Download cost is still 167 🙂

Good question Quarrel. I am happy someone is following along 😀 The reason is when I link the Animesh Tree to the Tree Physics model and set it to use the Animated Mesh option. the Animesh Tree gets displaced and then needs to be selected and repositioned to align with the Physics model. The problem is when I enable the Edit Linked in the build floater and have the Animesh Tree model selected and then try to move the arrows up or down the Animsh Tree does not follow along. Selecting the Tree Physics model moves both the Tree Physics and the Animesh Tree models together. In the gif anim. below the Animesh Tree is linked to the Tree Physics model (root). With Edit linked enabled I first I select the Physics Tree model and move it then switch to the Animesh Tree and try to move that. When both Animesh Tree and Physics Tree are linked to a Prim as root object then I still cant move the Animesh Tree but I can move the Physics model to align it with the Animesh Tree. I hope that I have explained that clearly enough?

If Physics is miss- aligned then do a quick check that scale and rotation have been Applied. (Ctrl A) Then check that BB(s) of Physics model(s) matches BB(s) of Visual model(s).

If you are having problems with some branches not having the same scale or orientation as the rest of the tree then you should 1: UV unwrap all the tree 2: In the UV editor orientate / allign all the islands along the same axis. 3: Select all the UV islands and scale up to suit your texture before exporting. Note: If your tree is composed of several objects then in object mode select all those objects > edit mode > select all > Uv unwrap all parts together. In the following example I separated the tree into 8 different objects: UV Unwrap all the parts at the same time: Orientate all the islands along the same axis (usually this will be vertically for a seamless bark texture) : Scale up all the islands together to suit the texture that you are using :

A very much modified version of your original "hoop" tree ! But I have removed the link now. Ok. We had (in my opinion) two options for lowering the LI cost. You have clearly eliminated one, animesh tree. Having only one option left should make things easier because now you can put all your energy and concentration into doing tests on the beta grid to find the best chopped up version that uses smaller smaller BB's and gives the lowest LI. Hint: chopping will probably include creating some custom lower LoD models. BTW I don't think your ref. tree has any collision surfaces, just saying ............... Or was the topic about how to create the leaves? One answer is to do them like most trees in Sl (including your reference tree) : use collections of billboards.

See my reply to Quarrel earlier in this thread. or try exporting (with the Avastar exporter) the rigged tree from this .blend : *removed Blender 3.1.0

This is the default Convex Hull physics shape the the uploader provides us if we don't specify a model to use for physics. The High LI is from the Download cost not the Physics cost. Check the Download and Physics numbers in the mesh uploader after you hit the Calculate Weights and Fees button. How do you reduce the Download cost ? As @ChinRey has already explained many times in these forums and again here : By reducing the file size, mesh complexity, number of tris and vertices etc and or reducing the objects size, BB, radius.

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 :

Hi Quarrel 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.

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

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.

There is a duplicated vertex hidden under one of the other vertices and it is part of an edge. When exporting the mesh is triangulated and this will result in a degenerate triangle. The "hidden" vertex is here : Select this hidden vertex and then X to open Delete menu and choose the Dissolve Vertices option then the Physics will upload without errors.

Clean up in 4 steps: 1: Edit mode, Vertex select mode, select All and Mesh > Clean Up > Merge by distance: 2: Clean Up > Degenerate Dissolve : 3: Clean Up > Limited dissolve : 4: any remaining unwanted vertices select and Dissolve Vertices : And as Frionil mentioned you will have to manually correct the zero thickness at the inner corners : .blend of cleaned up ramp : https://pasteall.org/blend/18d97a2bd9a04b9c9388040e1d28b0f5 Sometimes it just makes more sense to create from scratch in Blender !

Beq Janus (Firestorm Viewer Developer) fixed the Firestorm viewer so that it displays the correct (Render metadata) > Physics Shapes for mesh walls like in your example. See her blog from July 2017 that explains in detail what is happening : https://beqsother.blogspot.com/2017/07/a-convexing-problem-fixing-doors.html Quote from the end of the blog : " In the meantime, I have updated Firestorm to correctly reflect the enforced laws of physics. This should greatly improve the use of the physics view as a debugging tool. " Fixed in Firestorm but not in the LL viewer !

Sorted for now. Bounding Box mismatch and also using V shaped side panels in the Physics model were found to be better than two parralell panels at preventing avatars walking up and over the sides of the stairway.

Thanks Quarrel. I had problems with Blender 3.0 crashing when it first came out so decided to stick with version 2.93.5. I have since downloaded v3.1.0 but from habit continued using v2.93 . So a couple of screenshots this time Blender 3.1.0 First is an example of basic AO bake setup.Using Cycles and GPU. Note that the default Max Samples is set at 4096. For quicker test AO bakes this can be reduced to something like 32. Setup for more control, using an AO node connected to a Maths (power) node: With a bit more testing using the AO and Math node setup, enabling the Fast GI (Global illumination) Approximation doesn't seem to serve much purpose when baking out an AO map of a single object in a very simple scene. I found similar bake times with Fast GI Approximation checked or left unchecked.

Note that this is using Blender 2.93.5 See @Quarrel Kukulcan post below for Blender 3.0 I think the most basic set up for baking AO is the following : 1: Make sure hat you are using Cycles and if possible change Device to GPU. 2: In the 3D viewport change the Viewport Shading to Rendered. Next in the Viewport Shading drop-down change the Render Pass to Ambient Occlusion . Doing this will enable us to preview how the AO is effected on the model as we change the Distance value in the next step. 3: In the World properties tab enable Ambient Occlussion and set Distance to something like 1 m (depends on size of model). 4: In the Shader Editor add a new Image Texture node and from there hit the New button and give it a name something like AO Bake. It is very important to leave this Image Texture node selected (will be highlighted with a thin white border). Highlighting (selecting) this node tells Blender which image to bake to. 5: Go back to Render Properties panel. In the Sampling menu set the Render number to 16. While doing test bakes keeping this number low will speed up the AO bakes. When happy with the bake then bump up this value to something like 32 for a smoother bake result. 6: In the Bake menu change the Bake Type to Ambient Occlusion. Check the Clear Image option so that we write over the bake image every time we do a test bake . 7: Hit the Bake button and with any luck we will see the result in the UV editor. In the screenshot below options outlined in pink will effect how much AO will be seen on the model (seen in the preview and baked out in the AO bake image). To have more control over the amount of AO on the model we can Add an AO node in the Shader Editor and hook it up to a Math node with its function set to Power. (see screenshot below). This time for the preview in the 3D editor set Viewport Shading to Rendered as before but change the Viewport Shading drop-down > RenderPass back to Combined. In the Bake menu set the bake type to Diffuse and uncheck the Influence > Contributions > Direct and Indirect options. In the Shader Editor check that the Image Texture node, "bake AO" is still selected then hit the Bake button and check the results. This time it is the Exponent value in the Maths Power node that has most effect on the AO. But also try changing the Distance value in the Ambient Occlussion node. More often than not I have this at around 0.2. Everyone likes the Color Ramp node so here is another method explaining one way this can be used in combination with the AO node and an Emitter node : https://blender.stackexchange.com/questions/209358/baking-ambient-occlusion-almost-entirely-black Hope this helps

As arton has suggested, finding the relevant error log line will be easier if you uncheck the Show detailed logging option.

Once again you are not making it easy for anyone trying to help you. 1: A screenshot of your mesh objects in Blender. 2: Give your mesh objects more useful names. example: Walkway1 instead of Walkway_one Walkway2 instead of Walkway_one.001 because what happens if/when you later need to use the corect naming convention with the suffix _LOD2 _LOD1 _LOD0 and _PHYS the names become unnecessarily long. Same for BezierCurve.004 BezierCurve.005 etc. Not only are these meaningless but it could lead to confusion. "Is VK trying to upload BezierCurves instead of mesh? " If BezizerCurve.004 has been converted to mesh and is, for example one of two ropes on the left hand side of the Walkway then it could be named something like RopeWL1 (Rope, Walkway Left 1). Try to put yourself in the place of someone reading your question and ask yourself "have I given enough relevant information so that it is clear to another person what it is I am trying to do and what problems I have run into" Any ways, I have tried an upload of an earlier version of your Walkway (3 mesh objects) which used similar (long) names to the one you are uploading at the moment and the uploader gave an error which seemed to have something to do with the physics models. So as a quick test I added 3 cube objects to the scene. These would be used as physics models, 1 for each of the visual models and named them accordingly with the suffix _PHYS . Now with two .dae files (one for the 3 visual models and one for the 3 physics models) the uploader accepts the models without indicating any errors : So I am guessing all you need to do is upload physics models for each visual model.

Hi arton I saw VK's post and I am now inworld sorting this out with her now .

Using the Materials Specials menu to copy one material to another so that they are linked. Copy from selected to active object: First select the object that you want to have the material on (this is the Selected object) and then shift select the object that you want to copy from, ( the is the Active object) Open the Material Specials menu and choose the Copy Material to Selected option. Now both objects share the same material. (linked)