The CWA Board

I thought it would be better to turn this into a separate thread, so let's keep the optimize function of PT2 in here shall we? :)

Well I'm afraid using PT2 for its optimize function can still be critical in some cases. And applying this function can also change the vertices IDs...

True. I will take a closer look at pt2's optimize function to see what it does and how big the impact is on the 'cleanness' of the model and the file-size. We might be able to do this in max as well, but I have my doubts.

I thought that 3dsmax supports multiple texture-vertices per model-vertex, while Carmageddon does not. The optimize function suggests otherwise, so that might change the whole way the script currently looks at things. The solution might also be in just exporting the model in a different way.

Can you tell me in what cases the optimize function was critical for you?

edit 1:

Ok, a little investigating this morning makes me believe that the texture vertices and model vertices are indeed directly linked, but can be reduced by the optimize function as vertices can be re-used for multiple faces. I think what the PT2 optimize function does is search along the texture-vertices for identical ones and then removes the duplicates and rewrites the references internally. Here are some shots. I have used ADR's 64PU as an example, specifically the wheels:

In the first shot you can see the un-optimized vertexcount in pt2:


We can see the same thing in 3ds max These texture-vertices (or map-vertices) hold the x,y coordinates of the vertex in texture space. The actual model-vertices, the ones in 3d space with x,y,z coordinates, are 40. Multiply this by 3, as each face has 3 vertices, and you get 120 vertices. That indeed is very un-optimized!?!?!


Finally, after the using the optimize funtion you can see the number of vertices is reduced to almost half:


My first guess would be to start looking for identical map/texture vertices in 3ds max and re-write the exporter so that it will not generate duplicates. I think my initial guess was right; Carmageddon cannot have multiple texture-vertices per model-vertices. But it can re-use the same vertex multiple times.

Does that make sense?

Indeed, this is my understanding of how the PT2 optimise function works. Your VertexBuffer should contain only unique verts (C2 would define this as Position, Normal, UV and Colour) whereas your IndexBuffer would contain the appropriate index into the vertex buffer. See: http://rbwhitaker.wikidot.com/index-and-vertex-buffers

edit: just noticed I had a very inefficiently coded version of Optimise in my c2Mesh helper class

Seems to make sense to me as well. It's always the models with the more elaborated UVW maps that have to be the more optimized.
Go go Harm!

edit: just noticed I had a very inefficiently coded version of Optimise in my c2Mesh helper class

Thanks Errol! I already made a similar start with my code. :)

Could some of you guys test my new version of the exporter? I made a complete pack, but only the exporter has changed. It now exports optimized models directly!

Carmatools_20150119
(just extract it into your main 3dsmax directory, and run the carma_tools.mcr file from the main scripts directory to update the buttons)
If for some reason this doesn't work for you, just put back the old version with and run the mcr again. Old Version

As a side note: I noticed my code was already 2/3 years old and it sure is sloppy in some areas. Which means, I will continue optimizing and you can expect new versions in the course of the year. ;)

edit: side note 2: The vertex order in max is now very different from the one you will get in the game. I will have to write a proper carmageddon-vertex-index-displayer for this :). Coming soon!

The new version installed over the previous Carmatools alright. Did a comparison test between v30 and v33 with TDA's Master Of Disaster. Results look very good: (those are removed vertices, faces by PT2 on the exported scenes)

Didn't notice any degenerate geometry in the mesh or anything so far.

Keep it up, Harm!

Ah so there was still some optimizing done by PT2?

I think PT2 then still uses a threshold or rounding for the vertices, because I remove all exact duplicates. There probably are still some almost-duplicates left that can be removed.

Floating point maths, fantastic stuff
I read several papers on deduping floating point numbers before giving in and just using C# as my guide.

Kinda offtopic but as we're discussing the carmatools: I often have problems when importing DAT models into Max while keeping polygons intact. The mesh is clean and all, but the polygons are wrongly returned out of the triangles, if you see what I mean. And thus I just import fully triangulated meshes all the time. Exporting polygons seem ok so far!

Ah! I see what you mean and I will add it to the list. I remember having some issues with this myself, but thought I had it figured out in the end.

We might as well turn this topic in a Carmatools feature request topic

Oh then while we are at it, I think it'd just be nice to see improved support for C1 specificities?
Remember, C1 wants actors and models to have different identifiers. Would be cool to be able to set the model identifiers somewhere, and if two actors share the same model (indicated by having the same model identifier) then the exporter will only export the said model once. No idea how that can be set, maybe via a panel in the object properties?
Must pay attention not to conflict with noncars numbering and instances though.

In the same idea, C1 at least requires pixelmap in the .mat file to have the .pix extension attached. Could be a simple box to thick in the exporter and it would automagically add the extension while writing the .mat file. Or if you're courageous, it'd directly write a proper C1 .MAT file (04 type instead of 3C).

All this could help us generate files directly useable by C1 and we wouldn't have to hex edit them etc.

C1 at least requires pixelmap in the .mat file to have the .pix extension attached. Could be a simple box to thick in the exporter and it would automagically add the extension while writing the .mat file. Or if you're courageous, it'd directly write a proper C1 .MAT file (04 type instead of 3C).

Yes this would be easy to achieve. I will add it in the next release.

Remember, C1 wants actors and models to have different identifiers.

So if all models would have the extension '.dat' and all actors would have the extension '.act', would that be sufficient for c1? If I made sure that instanced models could be re-used by different actors, where the actor would have a index number that would work?

So if all models would have the extension '.dat' and all actors would have the extension '.act', would that be sufficient for c1?

Well not really, a simple example: wheel actors are always called FRWHEEL.ACT etc., with your method there the model would be called FRWHEEL.DAT. But then that could be conflicting with other cars that also use wheel model named like this.

When I work, I always use the 8.3 formatting and make use of prefixes. The jetcar for example: the main component is JETCAR.ACT and its model JETCAR.DAT. It uses several dummies for pivots and little tweaks. Wheels are FRWHEEL.ACT, FLWHEEL.ACT, RRWHEEL.ACT and RLWHEEL.ACT. They all use the model JETC_WHL.DAT. There's an aeliron AELIRON.ACT, model is JETC_AEL.DAT. You get the idea.

But you got me thinking a bit here. Nothing actually prevents me from naming the wheel actors like this: JETCW001.ACT, JETCW002.ACT, JETCW003.ACT and JETCW004.ACT. Your exporter could recognize the numbering pattern and then export a model named JETCW.DAT. The aeliron actor identifier could directly be JETC_AEL.ACT and would export a model accordingly named.
I guess this could all work, but it seems less natural to me.

Maybe it could just be a simple line manually added in the object properties that'd go like this:
RENAME_DAT_MODEL="JETC_WHL.DAT"
The exporter checks for such an entry, if it exists it reads it and thus exports the mesh with that identifier. As it progresses through the other components it'll end up on the other wheel actors which will have the same line with the same model identifier in their properties panel and will simply pass the mesh export as it's already been done.
It wouldn't be intrusive (I think), could be used with C2 scenes if necessary, but I don't know how feasible it is to code this

Also about the 04 type materials, pay attention that they are slightly different from the 3C type. They are a bit shorter. It's badly illustrated there: https://rr2000.cwaboard.co.uk/blog/index ... m-lighting