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

[FEATURE REQUEST] An option for composite objects/placement #13

Open
Flavelius opened this issue Jul 29, 2022 · 3 comments
Open

[FEATURE REQUEST] An option for composite objects/placement #13

Flavelius opened this issue Jul 29, 2022 · 3 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@Flavelius
Copy link
Contributor

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.

@dreadpon
Copy link
Owner

You can assign different materials in your 3D modeling software: one for trunk and branches and one for leaves.

Then after importing, assign the necessary shaders in your .mesh resource.

Unless you meant something else, this asset workflow enables different shaders for different parts of the mesh perfectly.

You can see this being used in my showcase project actually:

  1. trunks have a shader with one wind equation for sway
  2. leaves have a shader with 2 wind equations, one to mimic the trunk and other to simulate rustling of leaves themselves

@Flavelius
Copy link
Contributor Author

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 & 15 http://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.

@dreadpon dreadpon added the enhancement New feature or request label Aug 7, 2022
@dreadpon dreadpon added this to the v.2.0.0 milestone Aug 7, 2022
@dreadpon
Copy link
Owner

dreadpon commented Aug 7, 2022

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.

That's something I'll consider for v.2.0.0

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

No branches or pull requests

2 participants