You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem you're trying to solve in your project
Typically in games that are not lowpoly, trees are separated into branch and leaves because they usually don't share the same shader (branch->opaque, leaves->transparent/transmission/..). This addon supports placing whole scenes as colliders etc (which could be made up of multiple sub-objects, but doesn't seem to support rendering mesh-compounds/the same object composition of multiple meshes.
Describe a feature you consider and how it will help you
I could imagine something like linked/sub entries that are always placed together with a certain (maybe even configurable) offset between them.
Describe alternatives you've considered
Not assigning the mesh field, and instead just using the spatial field alone with the full meshed object assigned. This doesn't make use of multimeshing though and is thus less performant for many instances.
Describe how you imagine it would work. With code, pseudo-code, diagram or a drawing
There could be an extra field to name entries and another, or a dropdown, that one can assign any other entry to be linked to or just another nested sub-inspector. This could then optionally hide most of the properties of the linked entry inspector and just expose some offset settings. The system then, when placing instances while painting determines which are linked and always paints those together, with the same transformation as base + the offset of the linked entry appended.
The text was updated successfully, but these errors were encountered:
Sorry, this is embarassing. I'm probably just overworked. I'm working with 3D for many many years, but yesterday i was, for some reason, totally assuming that one mesh equals one material. You're right that meshes are not limited to one material ofcourse.
Although, it occured to me that this could still be useful to design 'clumps'/groups of grass with flowers, stones with rocks, trees with bushes, for example; meaning some that are always placed around others, in varying offsets (which is different to just painting them both randomly placed, see this pdf on page 14 & 15http://wiki.polycount.com/w/images/1/16/AllodsOnline-CreatingaWorldin7Days.pdf). This can ofcourse be done by manually creating a mesh in all variations, or by using 'single' placement and painting those, but it would be a lot less work to just define the clump/group center and the transform-offset-randomized clump/group-siblings as linked entries and being able to paint them in one go. Maybe this then requires using the 'single' paint mode, to ensure they don't overlap/intersect by default.
I suppose it should be done through linking different plants together, one being the 'driver' that places 'driven' plant around itself.
However, I don't think it makes sense to generalize placement algorythms. Instead, user might be able to provide his own script, and return an array of positions to use (by the plugin) for raycasting to the ground.
Describe the problem you're trying to solve in your project
Typically in games that are not lowpoly, trees are separated into branch and leaves because they usually don't share the same shader (branch->opaque, leaves->transparent/transmission/..). This addon supports placing whole scenes as colliders etc (which could be made up of multiple sub-objects, but doesn't seem to support rendering mesh-compounds/the same object composition of multiple meshes.
Describe a feature you consider and how it will help you
I could imagine something like linked/sub entries that are always placed together with a certain (maybe even configurable) offset between them.
Describe alternatives you've considered
Not assigning the mesh field, and instead just using the spatial field alone with the full meshed object assigned. This doesn't make use of multimeshing though and is thus less performant for many instances.
Describe how you imagine it would work. With code, pseudo-code, diagram or a drawing
There could be an extra field to name entries and another, or a dropdown, that one can assign any other entry to be linked to or just another nested sub-inspector. This could then optionally hide most of the properties of the linked entry inspector and just expose some offset settings. The system then, when placing instances while painting determines which are linked and always paints those together, with the same transformation as base + the offset of the linked entry appended.
The text was updated successfully, but these errors were encountered: