add Hull special texture

[azur-wolve]

There are cases where don't want a en entity to generate collision, due it being unnecessary complex.
The way-to-go is to make it func_illusionary / func_detail_illusionary and add a simple brush with CLIP texture to act as its collision shape.

But what when the entity marked as illusionary is of a type that is interacted, so there are collision layers involved, custom properties, etc.
In such cases want the auxiliary collision shape to be child of it, so the collision system can check which type is the collider, to apply any custom game logic. (check if is Interactable, etc.)

With the previous example there's a distinction between the illusionary entity and its auxiliary shape, because they are two separate entities that become 2 distinct nodes.

The problem can be addressed by applying some custom logic on map build.
But considering that it is a pretty common thing that almost any project could need..

What about have a special texture called "Hull", that behaves similarly to origin texture?

Workflow:

1. create illusionary entity
2. add to it a brush with Hull texture applied
3. on map build the brush disappears and instead a child ChollisionShape3D is attached to the entity it is subordinated to, presumably with a convex shape.

NOTE: doesn't necessarily mean that only should work on entities marked as illusionary / that doesn't generate any collision.

EDIT:
also to use a workaround on map build, the entity the hull would be applied to must have a script to do some lookup (like a relation target ←→ targetname) in an exported func_godot_properties, otherwise cant do reparenting properly.
Thats a problem when only want to add a simpler collision shape to a plain func_illusionary or func_detail_illusionary (with complex mesh) as those doesnt have any script attached.

[azur-wolve]

already have implemented one myself

it adds a collision shape on map build
allows both convex and concave

[RhapsodyInGeek]

Why use Hull when we can reuse Clip? Clip is intended to always provide a collision shape, so it makes more sense to expand it to something like this rather than create a whole new custom tool texture.

[azur-wolve]

the logic was that the brush with it applied gets added to an entity, similar to origin texture
and on map build it replaces the collision shape if has any, or adds if it hasn't

if the entity it gets added to specified concave or convex determines which shape type is generated.

in my current workaround im being forced to use 2 different entities: hull_convex and hull_concave as i have no way to let the logic run on map build to know if the target fgd entity is marked as either convex or concave before generating the collision shape.
(thats one of the main reasons think would be better to be built-in.)

the rest is boiler plate to move the generated collision shape that is child of the hull generated node to the target and then delete the hull node as isnt needed anymore, all to avoid having too many nodes (thats why not using CLIP for this)

right now I'm not quite sure how that relates to expanding CLIP texture.
could expand a bit if any idea?

maybe a good argument in favor of HULL texture would be separation of concerns.

[RhapsodyInGeek]

Well if all you're trying to do is create extra collision, Clip already creates collision without creating a mesh. That's its job.

What could be done is to add 2 options to the Collision setting on the SolidEntity definition: "Clip Only Convex" and "Clip Only Concave". Then it could build collision only from brushes that have Clip textures on them. No need for a hull texture, works within the pre-existing systems. Less interface bloat and it only touches one user-facing script and ends up as a small addition to geo generation.

[azur-wolve]

the advantage of having HULL texture would be that its more visual

so no need to switch from TB to Godot editor to manually check if a particular solid ent is marked as clip_only_* to know if a particular brush with CLIP texture will be its collision shape after map build.

better for mapping workflow/iteration

your proposed version still brings the functionality ofc

[RhapsodyInGeek]

If this were to get added, it would just be extending the Clip texture features. No need to overcomplicate / overdesign things. If anything we're trying to simplify the plugin as best we can without losing features.

I'll keep this feature in mind when we've gotten further with our core rewrite.