Resize units?

[Adeimantos]

Is there a way to easily change a units size in a mod? In bfme2 modding all you have to do is add: scale =2.0 to double a units size. That would be nice for a mythology mod, for making giants, great eagles, etc.

[Silier]

@vladislavbelov

[Lion.Kanzen]

@Lopess  hadn't done an experiment?

[Gurken Khan]

IIRC @Stan` said scaling is not possible.

[vladislavbelov]

12 hours ago, Silier said:

@vladislavbelov

I don't remember that feature.

[hyperion]

Guess adding scale wouldn't add any runtime cost as the models get converted to psa/pmd during build. Can't find a ticket on trac for it, so if you have use for this feature I suggest to open a bug.

[vladislavbelov]

On 07/11/2022 at 11:33 PM, hyperion said:

Guess adding scale wouldn't add any runtime cost as the models get converted to psa/pmd during build.

Wasn't the suggestion about the runtime scaling when you can override the scale by editing an actor XML?

[hyperion]

5 hours ago, vladislavbelov said:

Wasn't the suggestion about the runtime scaling when you can override the scale by editing an actor XML?

There is no scaling via actor xml as of yet, right?

As for the feature, I guess he wants to scale per entity (main actor and props alike), how to do it is up for debate.

The main use of such a feature I see that one could model with a realistic scale or for example shrink the current ships for testing.

[wackyserious]

19 hours ago, vladislavbelov said:

Wasn't the suggestion about the runtime scaling when you can override the scale by editing an actor XML?

I remember Warcraft III LARP maps with these, where they had in-game trigger spawners and scripts that can easily alter, the size color and other tweakable variables, good old WC3 days..

[wowgetoffyourcellphone]

6 hours ago, wackyserious said:

I remember Warcraft III LARP maps with these, where they had in-game trigger spawners and scripts that can easily alter, the size color and other tweakable variables, good old WC3 days..

I think the way they animated units back in the old days more easily allowed for scaling. I don't think they used skeletal animations back then; the animations were baked into the mesh or something (I forget the details, but the method is different than what modern games do).

[wowgetoffyourcellphone]

21 hours ago, hyperion said:

There is no scaling via actor xml as of yet, right?

I think it would be easy for non-animated objects, like randomly scaling trees for example, but not for units which use boned animations. 

[vladislavbelov]

On 09/11/2022 at 11:01 PM, hyperion said:

The main use of such a feature I see that one could model with a realistic scale or for example shrink the current ships for testing.

I think that kind of feature should be on the side of a 3D modeling software, because it might be more flexible there.

17 hours ago, wowgetoffyourcellphone said:

randomly scaling trees for example

That seems the most reasonable usage for that kind of scale.

[ChronA]

51 minutes ago, vladislavbelov said:

I think [unit rescaling] should be on the side of a 3D modeling software, because it might be more flexible there.

[Rescaling static props] seems the most reasonable usage for that kind of scale.

I think this misses the point of the complaint. The ability to rescale things DOES already exist in the 3D modeling software, and that is great for those who already know how to use these programs and want all that extra flexibility. But for anyone who doesn't know how to use Blender it is a huge impediment to their ability to mod the game. 

There are a bunch of potential applications where the ability to easily grow or shrink game models without changing any animations would be helpful: like larger projectiles so that its actually possible to see them in flight. Or ships and units that actually match the dimensions of their collision footprints. Or an AoE style tiny trees mod. These become huge projects if every model must be rescaled and exported from source, but would be almost trivial if there was just a number in an xml that could be adjusted in on the fly with a text editor.

[vladislavbelov]

3 hours ago, ChronA said:

I think this misses the point of the complaint.

I think I wasn't clear. In the first sentence I was talking about scaling a model on a way to converting from 3D model through DAE to PMD (our binary format to store a model/mesh).

3 hours ago, ChronA said:

The ability to rescale things DOES already exist in the 3D modeling software

It's true and that's why we don't have scaling on the mentioned step.

3 hours ago, ChronA said:

But for anyone who doesn't know how to use Blender it is a huge impediment to their ability to mod the game. 

It's simpler to have a link on wiki how to do that step for different editors than implementing and supporting that step in our engine.

 

My second sentence was about runtime scale. When you already have a single PMD of a tree and you want to place it on a random map with different sizes.

[ChronA]

2 hours ago, vladislavbelov said:

It's simpler to have a link on wiki how to do that step for different editors than implementing and supporting that step in our engine.

Is there a link on the wiki?

I've looked a bit for that sort of info for 0 AD (because I would like to have larger projectile models so I can tell who is shooting who) and I've not found anything.

 

[wowgetoffyourcellphone]

The game already has larger projectile actors you can use.

[Stan`]

Few things.

• PMD format doesn't support scaling whatsoever (PMD_File_Format  / PSA_File_Format ) - This is a bit annoying, since you need to do hacks to say, make a unit breathe, or change a muscle size when it flexes.
• You cannot scale models through templates. I suppose it's complicated because of props but @vladislavbelov might know more. I remember Sanderd17 talked about it in the past here 
• Ticket here #5259 (A method to adjust the visual scale of an actor.) – Wildfire Games

 

[hyperion]

On 11/11/2022 at 10:00 PM, wowgetoffyourcellphone said:

The game already has larger projectile actors you can use.

So adding scale means we could deduplicate some assets?

 

16 hours ago, Stan` said:

PMD format doesn't support scaling whatsoever

Well, you can generate different pmd/psa per scale, that's what I meant with build time / static scaling. Whether this is the most suitable way to go about it is another question.

 

16 hours ago, Stan` said:

I remember Sanderd17 talked about it in the past here

Not accessible

 

[Grapjas]

On 11/11/2022 at 10:00 PM, wowgetoffyourcellphone said:

The game already has larger projectile actors you can use.

[vladislavbelov]

1 hour ago, hyperion said:

Well, you can generate different pmd/psa per scale, that's what I meant with build time / static scaling.

It's not a good approach for GPU, as it means more data to store and process in comparison with what we have now.

[vladislavbelov]

On 11/11/2022 at 9:24 PM, ChronA said:

Is there a link on the wiki?

No, we don't have any kind of scaling yet.

[hyperion]

1 hour ago, vladislavbelov said:

It's not a good approach for GPU, as it means more data to store and process in comparison with what we have now.

There is zero additional overhead compared to using blender to scale the model, only less sources in the repo. Given the use cases in this thread there is no need to use the same model at different scale at the same time, but I see your concern that when you don't have to go through a lot of pain to scale a model "some random artist" will find it a good idea to have the same model be used at dozen scales at the same time.

[Stan`]

On 13/11/2022 at 11:56 AM, hyperion said:

Not accessible

Quote

I guess it's time to track my progress a bit better. So I'm making a few threads with stuff I'm working on (mainly for myself, but anyone may read and comment on it of course)

Scaling models works quite well up to now. I only have problems with lighting. I guess I somehow also scale the normals. As the light on a plane is calculated as "length(normal (dot) lightray)", this requires the normal to be normalized. Enlarging the normal causes brighter surfaces. So upscaling a model ends up with a brighter model, while downscaling makes your model darker.

As calculating the brightness happens differently in the different renderers, this will cause some additional testing.

So I'm pausing this work a bit, and just put the WIP patch here.

scaling.diff

The patch there is really old, probably doesn't apply

 

  

Quote

Some further thoughts on scaling props and other models. I'm thinking of adding a possibility to set a fixed scale on the prop line. Something like

<prop actor="props/units/heads/pers_kidaris_loose_tan.xml" attachpoint="helmet" scale="1.2"/>

Which would make the helmet for that unit 20% bigger. Because there's uniform scaling, it won't mess up the normals, and since there's no variation, it also won't mess up the AO map when used for building props. Props can have child props, so the scale is passed on to lower levels (and multiplied if there are new scale definitions for the child props). This means that the scale is always relative to the parent, and not to the world.

Secondly, I suggest adding the possibility for scale variation on the Actor level. Something like

 <VisualActor>
    <Actor>flora/trees/pine.xml</Actor>    
    <Scaling>      
      <Min>0.8</Min>      
      <Max>1.2</Max>    
    </Scaling>  
</VisualActor>

This would make the size of the pine tree variate between -20% and +20% of the original model size. The actual scale will be determined by the seed that also determines the variation on models. So if you make a map, the big pines will always be in the same place. But you wouldn't need 5 meshes just for different pine sizes. Again, this root scale is passed on to all child props when necessary. Maybe the there should be a choice between some different distributions, that can be added when there's a sensible way to note it in the template schema.

What do you think of it? Is it too complicated? Not versatile enough? Is it defined on the right levels? I can implement the schema above in a day or two (when there's a decision).

 

 

23 hours ago, hyperion said:

There is zero additional overhead compared to using blender to scale the model, only less sources in the repo. Given the use cases in this thread there is no need to use the same model at different scale at the same time, but I see your concern that when you don't have to go through a lot of pain to scale a model "some random artist" will find it a good idea to have the same model be used at dozen scales at the same time.

My main usage would be putting siege engines on towers and ships without requiring to resize them. Obviously it would make scaling boats much easier because we don't need to worry about messing the armature. Importing animated meshes in blender is discouraged, and we don't have all the source files.

[hyperion]

4 hours ago, Stan` said:

The patch there is really old, probably doesn't apply

Plenty good enough to show the approach, thanks. Does the scaling at load time and I guess @vladislavbelov favorite is the randomized scaling to ensure there are no two same models. Reading between the lines I guess @vladislavbelov would want the scaling be done on the gpu tho.

A good point brought up is how scale inheritance should be figured out as well.

[vladislavbelov]

16 minutes ago, hyperion said:

Reading between the lines I guess @vladislavbelov would want the scaling be done on the gpu tho.

The most interesting thing is that scaling is already done on the GPU side (as we use a complete transform matrix) So we need to calculate that matrix properly on the CPU side to account a possible scale.

18 minutes ago, hyperion said:

ensure there are no two same models.

Exactly.

On 13/11/2022 at 5:08 PM, hyperion said:

"some random artist"

The problem is that we only have "that kind of active artists". There is no art reviewer who'd say how art should be done properly in terms of performance.

And I don't have time to finish my "Techinical Art Guidelines". Spoiler to it:

Spoiler