Terrain adapting, towerless palisades

[nifa]

Hey folks,

I tried around with the palisade and had the idea to make every trunk a single prop, which adapts to the height of the terrain, so that it has a nicer look on hilly terrains and the towers inbetween are (almost) obsolete. Let me know what you think of it

It works good, some problems are left though. The tower is a single stick now, which doesn't make much sense. Sometimes the "stretching" leaves too much space in between or produces overlapping. I think those things could be solved by editing simulation/helpers/wall.js, but unfortunately I don't know javascript, maybe somebody would like to dig into it.

I'd like to add more faction-specific lower walls, if that works. It wouldn't work with stone walls though

 

[alre]

question: has this any impact on performances?

[nifa]

1 hour ago, alre said:

question: has this any impact on performances?

the number of tris isn't necessarily higher. Don't know if props are an issue regarding performance, but i don't think so

[vladislavbelov]

9 hours ago, alre said:

question: has this any impact on performances?

Currently - yes, especially CPU for low-end hardware.

[Stan`]

Basically each new object is a new command to the GPU. 1000 objects -> 1000 commands. So it could be 1000 times more expensive to do it.

[nifa]

8 hours ago, Stan` said:

Basically each new object is a new command to the GPU. 1000 objects -> 1000 commands. So it could be 1000 times more expensive to do it.

Well right now the template for the long palisade consists of one palisade_long.xml, which sets the trunk in the middle, and 24 props for each of the other trunk. So if I get this right, props should be avoided? Does it make a difference, if I use the same prop multiple times?

I could make groups of e.g. 5 trunks for each prop, so each palisade_long.xml would only have 4 props. Would that save GPU/CPU?

[Stan`]

In general yes, until we have instancing, which would batch them assuming they are the same mesh and texture.

4 minutes ago, nifa said:

Does it make a difference, if I use the same prop multiple times?

Currently no.

4 minutes ago, nifa said:

 

I could make groups of e.g. 5 trunks for each prop, so each palisade_long.xml would only have 4 props. Would that save GPU/CPU?

Sure but that'd still be worse than the current one. Probably not so bad assuming not too many are on screen.

[hyperion]

Looks so much better that I personally wouldn't care about the performance and use it if you provide a mod

[Lion.Kanzen]

On 27/04/2023 at 1:27 PM, nifa said:

Hey folks,

I tried around with the palisade and had the idea to make every trunk a single prop, which adapts to the height of the terrain, so that it has a nicer look on hilly terrains and the towers inbetween are (almost) obsolete. Let me know what you think of it

 

It works good, some problems are left though. The tower is a single stick now, which doesn't make much sense. Sometimes the "stretching" leaves too much space in between or produces overlapping. I think those things could be solved by editing simulation/helpers/wall.js, but unfortunately I don't know javascript, maybe somebody would like to dig into it.

I'd like to add more faction-specific lower walls, if that works. It wouldn't work with stone walls though

 

It looks good, I always thought that the palisades will use the old system of putting up walls.

[Lion.Kanzen]

20 minutes ago, Lion.Kanzen said:

It looks good, I always thought that the palisades will use the old system of putting up walls.

 

 

 

 

[nifa]

3 hours ago, hyperion said:

Looks so much better that I personally wouldn't care about the performance and use it if you provide a mod

Thanks! Here's the mod So far it only adds the new one for romans

Palisades.zip

Edited April 29, 2023 by nifa

[hyperion]

1 hour ago, nifa said:

Thanks! Here's the mod So far it only adds the new one for romans

Thanks as well!

Some tips for packaging a mod:

• Mod is named palisades (lowercase (good)) in mod.json, so should live in a directory palisades (lowercase), only some windows filesystem don't care about case.
• Mod (the zip archive) should not have a root folder "Palisades" to allow installation via drag and drop / open with ... / as argument to 0ad on CLI.
• Naming convention is <mod name>-<mod version>.zip, ie. palisades-0.0.1.zip
• Mod version ideally gives a hint as to which alpha it's compatible with, ie. 0.27.0 would be a decent pick, then the next iteration for the same alpha would be 0.27.1

Guess only the second point is really important as it allows to share mods with everyone and not just tech savvy people.

[nifa]

On 29/04/2023 at 6:20 PM, hyperion said:

Thanks as well!

Some tips for packaging a mod:

• Mod is named palisades (lowercase (good)) in mod.json, so should live in a directory palisades (lowercase), only some windows filesystem don't care about case.
• Mod (the zip archive) should not have a root folder "Palisades" to allow installation via drag and drop / open with ... / as argument to 0ad on CLI.
• Naming convention is <mod name>-<mod version>.zip, ie. palisades-0.0.1.zip
• Mod version ideally gives a hint as to which alpha it's compatible with, ie. 0.27.0 would be a decent pick, then the next iteration for the same alpha would be 0.27.1

Guess only the second point is really important as it allows to share mods with everyone and not just tech savvy people.

Alright thanks, I changed it and will keep it in mind for a possible new version:)