Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignored parameter "mesh_instance/visibility_range_begin" on asset #201

Open
why-try313 opened this issue Jun 14, 2024 · 5 comments
Open

Comments

@why-try313
Copy link

The problem:

As said on the title, ScatterShape ignores the parameters [mesh_instance].visibility_range_begin, [mesh_instance].visibility_range_end and margins set on the model , which makes the assets with low poly versions into one merged mesh.

Note that I did search for this setting on the menu, it's either not present or hidden under some menu


A visual representation

In this example, there's 2 models, a LOD set on a .gltf file and distances set via the integrated godot importer, and a second model without low levels meshes.
When the LOD object is set to ScatterShape, all meshes are displayed
scatter

Solutions

I dond't know if the code implies a remesh of the model or a small bug but if it's not a bug, a simple "Ignore remesh" boolean button could be added to the ScatterShape menu, set false by default, to either use the addon method or the godot method

@HungryProton
Copy link
Owner

Try to set the visibility properties on the ScatterItem node (not the main scatter one, or the shapes, the item node). It's under the visibility sub menu, in the inspector.
You can disable the auto LOD generation in the Level of Detail submenu. If you still have LOD issues, then it's a bug I still need to fix.

@why-try313
Copy link
Author

First of, thanks for the fast reply !
To answer, been there, done that:

  • the visibility_range_begin parameter (Visibility > Range begin) does its job but in the mushed version (left on the example image), meaning the LOD does its job but on the model that considers as one, single, not LOD set model, so no chances on that
  • the lod_generate is currently false in the examples, which gets that result

I tweaked some of my models to use script on import (and without the script it's the same result, so it's not the script) and I know that the importer script returns a scene, maybe using the result of the imported scene instead of the model itself could be a quick way to fix this?

If it can help, a sample of a script used on the importer:

@tool # Needed so it runs in editor.
extends EditorScenePostImport
func _post_import(scene): # called by the importer
    do_something(scene)
    return scene # the function expects to return the modified scene

@why-try313
Copy link
Author

why-try313 commented Jun 15, 2024

@HungryProton my bad!
The functionality is integrated, if [ProtonScatter]render_mode is set to Create copies the addon works as expected.

image

I guess the problem was with the cached obects (?).
After digging into the code get_merged_meshes_from did mush all the meshes into one since it had less than 8 surface # Less than 8 surfaces, merge in a single MeshInstance but setting it to Create copies still used the cached mushed version, clearing all out and setting the render_mode before setting the object uses the default godot loader.

I guess the bug is more about cache than logic, i'd suggest to test and close if the problem is not confirmed, might be a specific case unrelated to the addon

@HungryProton
Copy link
Owner

It's a bit complex:

By default, scatter uses instancing to speed up the rendering.

  • Instancing is only useful when you have a lot of instances in a tight space.
  • Grass is a good candidate, but for sparse trees, create copies is enough (it will just instantiate a full copy of the scene without trying to optimize anything).

Instancing uses a MultiMeshInstance3D node under the hood, however it handles materials differently:

  • Regular meshes can have materials on three different places:
    • On the mesh surfaces
    • On the mesh instance surfaces overrides
    • On the mesh instance material override
  • Multimeshes on the other hand don't have the surfaces overrides.

So when using instancing with a mesh with surface material overrides, Scatter has to create a new mesh and set the materials to the mesh surface instead (I can't reuse the original mesh here or it might mess up the materials for another scene using the same mesh).

Recreating that mesh makes it lose its custom LOD, and that's something I need to investigate.

@why-try313
Copy link
Author

I'd say it works "as intended"
The logic goes:

    [Scatter] _update_multimeshes():
        [Util] get_or_create_multimesh(item)
            [Utils] get_or_create_multimesh(item)
                mesh = ImporterMesh.new()
                -> mesh.add_surface(PRIMITIVE_TRIANGLES, item[suface].mesh)
                # Here, item still has the visibility paramaters, but the
                # importer loses it when surfaces are ingested which is normal since
                # the vertex are passed to `Mesh.PRIMITIVE_TRIANGLES`
            returns a Mutlmesh with lost visibility settings

Using ImporterMeshInstance3D instead of ImporterMesh could be an option since ImporterMeshInstance3D has the visibility options, but I would imply having separated meshes anyway to have that visibility option set per mesh, which doesn't work for optimization

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants