How to fix/merge sections in parts from old models

[Sergei_Q 0]

Next step is going to "Face" menu and selecting "Sort"

Often after this operation number of sections displayed doesn't want to update right away, so we go into another LOD and then come back to editing same LOD.

WOW! Just doing that dropped section count from 43 to 24!

However, doing so seems to have an undesired side effect, making one of my car interior textures invisible through car windows. I wonder why?

[Jackal326 1181]

Next step is going to "Face" menu and selecting "Sort"

Often after this operation number of sections displayed doesn't want to update right away, so we go into another LOD and then come back to editing same LOD.

WOW! Just doing that dropped section count from 43 to 24!

However, doing so seems to have an undesired side effect, making one of my car interior textures invisible through car windows. I wonder why?

Its also sorted the alpha layering (responsible for the hiding of the interior). Just select the faces using the interior texture and hit CTRL+SHIFT+END to solve the issue (hopefully).

[Sergei_Q 0]

That did it! Thanks, now I'm a very happy camper!

[feersum.endjinn 6]

Quick question about sections.

In some of my lods, I have a section called "not mapped" that is associated with the zesleh proxy does this count as a section or is it ignored?

It doesn't really count, as it is only rendered when weapon is firing.

I guess ArmA could in theory have two different index buffers for when weapon is firing and when it's not, but I doubt memory:gpu cycle tradeoff would be worth it

[Linker Split 0]

yo guys any way to fix this problem in the models made with O2 for ArmA? not importing them from OFP... I tried everything, nothin happened..

Linker,first make sure each textured polygon has an rvmat assignment or o2 might assume each or some are a unique section.

not solved,then make sure any model parts are not mistakenly textured with a different sections attributes,for example a few small "gear texture" polys are unnoticably textured with a "uniform texture" by mistake,this will cause problems as the polys belong to different parents.

Ok, I solved the problem, thanks anyway

[[aps]gnat 28]

Why is it when I rename all my textures (including BIS default referenced one) to TGA from PAA (ONLY IN O2, not the actual file) I get significant section count drops from 20 to 12 !! ??  

In my Resource window I have "?" beside all BIS textures because it can't find the .TGA version of the texture, yet its reduced the section count.

All seems to work fine in Buldozer.

Only thing it doesnt like is if I have a PAC file and I try renaming it to TGA (in o2). Buldozer says it cant find the PAA version of the file.

[Panda-PL- 0]

It would be great, Gnat, if BI added an automerge function when converting upon binarisation (lol, kind of obvious feature, wonder why they DIDN'T).

Have you tested if it does anything with TGAs?

But it's possible it's just a bug.

[[aps]gnat 28]

@ June 23 2008,01:31)]It would be great, Gnat, if BI added an automerge function when converting upon binarisation (lol, kind of obvious feature, wonder why they DIDN'T).

Have you tested if it does anything with TGAs?

Well, yes maybe, but its hard to tell what everyone elses setup actual does compared to mine.

Mine WAS perfect in many ways.

- I could edit TGA files and when I went back into O2 it would recognise a updated TGA and run them through Buldozers own converter and make a new PAA file for me.

- This would also instantly (well almost) update the visual in Buldozer ...... perfect

That still all happens, but now when I PBO up (not Binize) the addon folder for testing (all files, TGAs and PAAs) it now gives me a "Make not available blah blah TGA file" ......

Never used to.

Now I have to make a copy of the folder, delete all TGAs, then PBO it. Works fine then.

[Synide 0]

didn't i mentioned before in your other thread regarding this... there is only one reason this

Quote[/b] ]"Make not available blah blah TGA file"

error message comes up in ArmA. And that is because somewhere you have a face pointing at a .tga... more than likely it's in a .rvmat somewhere... but just as easily it's in your main model if you haven't binarized it...

While pointing one or more faces in your model at a .tga and then running Buldozer converts the .tga to a .paa it doesn't actually change the face(s) pointing to the .tga(s) to .paa(s) unless you binarize the model...

If it's your common practice to not binarize your model (for instance during development phase) then I suggest you don't point faces at .tga's and make sure your .rvmat's (in text form) also do not point at .tga's...

Personally I never make a .pbo without binarizing it from the very first instance... it greatly helps in making sure everything is well & good from the the beginning...

And makes sure that not only does it convert the .tga's to .paa's but it also automatically changes the 'references' in the p3dm mlod model from .tga to .paa and changes the references from .tga to .paa in the .rvmat's...

You can't have you cake and eat it too... if you wanna work with .tga references then binarize... if you don't want to binarize all the time then make sure everything points at .paa's...

[[aps]gnat 28]

You can't have you cake and eat it too... if you wanna work with .tga references then binarize

Yes, I hear you but as I said, I DID have my Cake and I WAS eating it .. all, until what appears to be the first time I used binarize (since the last release of the tools).

Now its a problem, and I can find NO references to TGAs in my RVMATs etc

Thanks anyway. More experiementing / testing / investigating to do I guess.

Anyway, off-topic.

[DaSquade 0]

Maybe not directly the correct topic as it doesn't effect sections, but since this is a bit a 'clean-up' topic...

It might be worth mentioning that one also needs to look if your model doesn't contain blank UVsets. Although i haven't played around with multiple UVsets, i did encounter some errors where i had imported a modo model with several different UVs and due to editing in modo itself (copy/past) it had imported a blank UV set.

During binarizing the pbo i noticed the debug text mentioned LODX contained additional UV sets with errors. I forgot the exact codeline, but in short it turned out the model had indeed a secondairy UV set with no data (=blank) witch left some errors in the debug.

To fix:

Simply go to the effected LOD and check: Surfaces->UVsets

Check if you have more then 1 UVsets.

If you have more then one (and only use one), make the unused one 'active' and then 'delete active'.