Im currently trying to add the tilefade feature into TNO trees. Im simple notepad modeller so I have few questions:
May I change the name of certain node? some models have nodes named without hint what this node represents ingame, when changing nodes I need to change it one by one and always run module to test which polygon it changed ingame. While its then to no use for me, someone else in future could appreciate when I would renamed them to "branches01" etc.
Also, I found out certain models have sub-parent-node and some polygons are bound with this subnode instead of parent node which means that tilefade option does not work. When I removed link to this node and changed it into parent node tilefade worked however I noticed flickering ingame. Is this a reason why there is this subnode?
model nodes and its properties question
Débuté par
Shadooow
, juin 15 2012 04:33
Retour en haut
#2
Posté 15 juin 2012 - 04:57
_six
-
- Members
- 919 messages
If you rename a node, make sure you rename all references to it in the model (ie if you change "trimesh Object01" to "trimesh Tree", then change "parent Object01" to "parent Tree" everywhere in the model). Otherwise you shouldn't have issues with renaming.
If you're referring to the <tilename>a node, that's what is generally referred to as the animation dummy. Any animated objects on a tile need to be attached to it. It also has two side effects on nodes attached to it.
- Firstly, it forces the attached objects to be rendered last, even after objects listed afterwards in the model.
- Secondly, it disables the use of tilefade on any objects attached to it.
The render issue is a concern for things with transparency such as trees as to be displayed correctly they need to be sorted from back-to-front from the camera's perspective. Otherwise you get the 'ringing' effect you see on a lot of the standard assets around railings etc. However, anim dummy aside, the engine basically renders objects in the order they're listed in the model file. So you can preserve render order by moving the whole foliage mesh node to be the last node in the file.
If you're referring to the <tilename>a node, that's what is generally referred to as the animation dummy. Any animated objects on a tile need to be attached to it. It also has two side effects on nodes attached to it.
- Firstly, it forces the attached objects to be rendered last, even after objects listed afterwards in the model.
- Secondly, it disables the use of tilefade on any objects attached to it.
The render issue is a concern for things with transparency such as trees as to be displayed correctly they need to be sorted from back-to-front from the camera's perspective. Otherwise you get the 'ringing' effect you see on a lot of the standard assets around railings etc. However, anim dummy aside, the engine basically renders objects in the order they're listed in the model file. So you can preserve render order by moving the whole foliage mesh node to be the last node in the file.
#3
Posté 15 juin 2012 - 05:15
Shadooow
-
- Members
- 4 474 messages
ok thanks for explanation, and yes i was reffering to the <tilename>a node. Ok then I guess I have to leave it as it is. So far, that was only issue of this fruit tree along road.
Oh and one more question: does the compiling the model improves loading time? Found out that all models from 1.69 (items, placeables, tiles) are not compiled.
Oh and one more question: does the compiling the model improves loading time? Found out that all models from 1.69 (items, placeables, tiles) are not compiled.
Modifié par ShaDoOoW, 15 juin 2012 - 05:17 .
#4
Posté 15 juin 2012 - 05:58
_six
-
- Members
- 919 messages
ShaDoOoW wrote...
ok thanks for explanation, and yes i was reffering to the <tilename>a node. Ok then I guess I have to leave it as it is. So far, that was only issue of this fruit tree along road.
Not really. As I hoped to get across, you can cut and paste the text from "node trimesh" up to "endnode" on the specific object you're after, and place it before "endmodelgeom" to get the same transparency fix without breaking tilefade. Then set the parent to the base model dummy.
Theoretically, compilation does improve things but I'm not sure by how much. With a few exceptions (I'm thinking of the willow trees here) I can't see it making a marked difference. Plus I don't know about you, but TNO areas load in a couple of seconds on my PC these days so I dare say compiling the whole TNO set is more trouble than it's worth. And you should definitely not compile anything with skinmesh or animesh involved, so at the very least any sea tiles need to be uncompiled.
Modifié par _six, 15 juin 2012 - 05:59 .
#5
Posté 15 juin 2012 - 06:22
Shadooow
-
- Members
- 4 474 messages
Ok, I still dont understand why, but did what you told me and it worked without flickering, so thanks!_six wrote...
ShaDoOoW wrote...
ok thanks for explanation, and yes i was reffering to the <tilename>a node. Ok then I guess I have to leave it as it is. So far, that was only issue of this fruit tree along road.
Not really. As I hoped to get across, you can cut and paste the text from "node trimesh" up to "endnode" on the specific object you're after, and place it before "endmodelgeom" to get the same transparency fix without breaking tilefade. Then set the parent to the base model dummy.
Theoretically, compilation does improve things but I'm not sure by how much. With a few exceptions (I'm thinking of the willow trees here) I can't see it making a marked difference. Plus I don't know about you, but TNO areas load in a couple of seconds on my PC these days so I dare say compiling the whole TNO set is more trouble than it's worth. And you should definitely not compile anything with skinmesh or animesh involved, so at the very least any sea tiles need to be uncompiled.
As the compilation, I probably compile all models I have changed, but due to the file size of models from TNO, cannot really compile them all as this work goes to the community patch and filesize is a factor.
One more question, as you told me in another thread, some tree tiles indeed have tilefade option already and I found out that these models have a value of 4 for tilefade the vertical cover polygon on the edge of the tile. Seems intended, so what does value of 4 means? Are there other values as well?
Modifié par ShaDoOoW, 15 juin 2012 - 06:25 .
#6
Posté 15 juin 2012 - 08:10
_six
-
- Members
- 919 messages
Tilefade values 2-4 are used for things that should only be visible when tiles are faded. So if you take the cliff in the forest tileset as an example, the upper cliff wall and the top black panel are set to 1, which is fade. However the sides and the secondary black 'top' that appears when the upper section has faded are set to those other values. They're quite specialist use and generally only result in a few polys savings when tilefade is inactive so I would tend towards not playing with them.
I don't remember what each value represents but I'm sure it was explained by OldMansBeard on these forums at some point (I just can't find it). Whilst looking, curiously I stumbled upon a year-old thread you started on this same topic in which Bannor incorrectly advised you that an anim dummy was necessary to render transparency, which might explain why the TNO tileset has that by default.
I don't remember what each value represents but I'm sure it was explained by OldMansBeard on these forums at some point (I just can't find it). Whilst looking, curiously I stumbled upon a year-old thread you started on this same topic in which Bannor incorrectly advised you that an anim dummy was necessary to render transparency, which might explain why the TNO tileset has that by default.
Modifié par _six, 15 juin 2012 - 08:14 .
#7
Posté 15 juin 2012 - 08:25
Shadooow
-
- Members
- 4 474 messages
Yeah, I knew I asked already but forgot and couldnt find it via google search, now when I tried to search for different key words I found it out, nevertheless this time I learned more_six wrote...
Whilst looking, curiously I stumbled upon a year-old thread you started on this same topic in which Bannor incorrectly advised you that an anim dummy was necessary to render transparency, which might explain why the TNO tileset has that by default.
thanks six_
