Anonymous Login
2019-07-24 00:26 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001300OpenClonkEngine - Graphicspublic2017-12-27 10:27
ReporterMarky 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusacknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0001300: Feature Request - CreateParticleAtBone for attached meshes
DescriptionIt would be useful if we could create particles at the bones of attached meshes. For example if the musket or similar weapons have a "muzzle" bone, then I want to create the muzzle flash effect at that bone.

The implementation could be one of the following versions:
1) The function searches in the bones of attached meshes automatically - bad if there are equal bone names in both skeletons.
2) Add a parameter for the attached mesh number, nil being the parent mesh.
3) Call CreateParticleAtBone() in the object (in the example: musket in inventory) providing the mesh. May look more intuitive in the code, but obviously works only if you attach the mesh of an object, not that of an ID.
TagsNo tags attached.
Attached Files

-Relationships
related to 0001249resolvedMarky Fire particles of incinerated powder keg are at clonk's center when being carried. 
+Relationships

-Notes

~0003574

Sven2 (developer)

Last edited: 2015-04-06 18:34

View 2 revisions

Solution 1) You already mentioned the problem. Even if bones names were unique, the clonk can carry two items of the same kind with one in each hand.

Solution 3) Would be nice, but I think graphics of a single object can be attached to multiple meshes and also the original object may still be drawn. Also, I don't know if an object "knows" where its graphics are attached. It would have to search the whole object list.

So it would pretty much have to be solution 2)

~0003575

Clonk-Karl (administrator)

An object knows where it is attached, and I think actually that one object can at most be attached to one other mesh.

I'd still prefer solution 2, though, for consistency with most other mesh functions.

~0003942

Sven2 (developer)

@clonk-karl: Solution 2 is more consistent, but also more annoying in script: Every object that can be carried and can cast particles at a bone would have to do the "if(Contained() && Contained()->IsAttachingThisObjectAsMesh()" function. In this scenario, having the engine do that seems more intuitive to me.

Alternatively, we could define CreateParticleAtBoneForCarryableObjects() which does the checks. But then I wonder what the use case of the unmodified function would be.

What about doing both 2 and 3? I.e. allow the parameter, but also auto-forward particle creation for attached meshes?

~0003943

Clonk-Karl (administrator)

When attaching an object, in principle it is rendered twice: the object stand-alone, and the object attached to the parent mesh. This is typically not seen, because objects are only attached when they are contained in something. If we do both 2 and 3, we would lose the option to create particles relative to the un-attached version of the object. But I cannot think of a situation where one would reasonable want that, so I think it's fine -- the pros probably outweigh the cons.

~0003944

Sven2 (developer)

We can add a parameter to force creation at the original mesh if ever need it. For example, the mesh attachment parameter could be 0 to force creation at the original object (and nil, i.e. default, to auto-forward to the attachment).

~0003950

Clonk-Karl (administrator)

It would still be ambiguous for nested attachments. If you have ID A attached to object B attached to object C, and you call CreateParticleAtBone() on B with the attach_number parameter set to the number of object A. Would you then get the particle at the position of object B (stand-alone), or at the position of object C (your "auto-forward")? The problem is that normally the attach_number parameter is used to go "down" the attachment tree, whereas in this case we would want to go up.

I think we should just always auto-forward (actually it's rather auto-backward, since you walk up the attachment hierarchy ;)). If at some point we need the other version, we can either add an extra parameter just for this, or create a second function for it.
+Notes

-Issue History
Date Modified Username Field Change
2015-04-04 15:32 Marky New Issue
2015-04-06 18:33 Sven2 Note Added: 0003574
2015-04-06 18:34 Sven2 Note Edited: 0003574 View Revisions
2015-04-07 01:59 Clonk-Karl Note Added: 0003575
2015-10-16 12:12 Clonkonaut Status new => acknowledged
2015-10-16 14:52 Sven2 Note Added: 0003942
2015-10-16 15:01 Clonk-Karl Note Added: 0003943
2015-10-16 15:06 Sven2 Note Added: 0003944
2015-10-16 23:22 Clonk-Karl Note Added: 0003950
2017-12-27 10:27 Marky Relationship added related to 0001249
+Issue History