Ticket #1237 (new enhancement)

Opened 14 months ago

Last modified 13 months ago

Add rotation attribute to variant element in Actor files

Reported by: Pureon Owned by:
Priority: Nice to Have Milestone: Backlog
Component: UI & Simulation Keywords:
Cc:

Description

For a click-drag wall building system it would be useful to have an actor variant where the model is placed rotated 180°, while another variant of the model is placed 0° - this would make walls less visually repetitive and reduce the need for additional models or textures.

Within the actor file I see the 'variant' element with a rotation of 180° working like this:

<variant frequency="100" name="wall" rotation="180"/>

<mesh>structural/celt_wall.dae</mesh>

</variant>

'rotation' is the new attribute. The degree of rotation 1 to 359

Would also be useful for other 3D models like crates and barrels to add visual variety.

Change History

comment:1 follow-up: ↓ 2 Changed 14 months ago by historic_bruno

Some considerations:

  • Is it better to specify every possible variation (which only vary by rotation/translation) or have some parameters in the actor that are randomized?
  • I agree with Philip's comment in IRC, this should be fairly generic so both rotation and translation can be specified.
  • We'd have to be careful using this, because it seems like the visual actor might be offset from the actual footprint/obstruction which could lead to unexpected results.

comment:2 in reply to: ↑ 1 Changed 14 months ago by Pureon

Replying to historic_bruno:

My responses to your points:

1) Could something like this work: <variant frequency="100" name="wall" rotation="0,90,180,270"/>

3) All wall models will be centered on the origin/root. I don't see this being an issue for walls at this stage.

comment:3 Changed 14 months ago by michael

This would definitely be nice for houses. Either way we do it, I will work with. Though, I think whatever is cleanest and easiest would be best.

comment:4 follow-up: ↓ 6 Changed 14 months ago by Philip

Syntax could probably be like

<actor ...>
  <group>
    <variant>
      <mesh>...</mesh>
      <texture>...</texture>
    </variant>
  </group>
  <group>
    <variant frequency="25" name="rotate0">
      <transform rotate="0"/>
    </variant>
    <variant frequency="25" name="rotate1">
      <transform rotate="90"/>
    </variant>
    <variant frequency="25" name="rotate2">
      <transform rotate="180"/>
    </variant>
    <variant frequency="25" name="rotate3">
      <transform rotate="270"/>
    </variant>
  </group>
</actor>

so that we reuse the standard randomisation thing to select the appropriate transform to apply to the model.

But one problem with this is that if you have multiple actors propped onto a single unit, and all those actors have "rotate0" and "rotate1" etc variants, then the engine will pick the same variant for every one of those actors, so the props will all stay in rotational sync with each other. I suppose we need support for some other syntax to allow variants that are local to the current actor and don't propagate across props.

comment:5 Changed 14 months ago by Philip

...or if we don't (and never will) actually want the current feature that if two props use the same variant names then they will stay in sync (i.e. if one prop picks variant "A" and a second prop has a variant named "A" then it will always pick "A" for the second prop too), we could just remove that feature entirely.

comment:6 in reply to: ↑ 4 Changed 13 months ago by Pureon

Replying to Philip:

That prop feature may already be used somewhere. Michael do you know?

Other than that your syntax does what Michael and I need, and if it conforms to the standard approach we should go with that.

If an actor file doesn't contain a variant with a <transform rotate="X"/> element, will it default to 0°?

Note: See TracTickets for help on using tickets.