PT2's optimize function
User avatar
Harmalarm created PT2's optimize function on Sun Jan 18, 2015 10:18 am
Post
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? :)

Quote:
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:
Image

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!?!?!
Image

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

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?
User avatar
Errol on Sun Jan 18, 2015 11:31 am
Post
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
User avatar
Toshiba-3 on Mon Jan 19, 2015 12:50 pm
Post
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! :ssmile:
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Mon Jan 19, 2015 6:02 pm
Post
Quote:
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. :)
User avatar
Harmalarm on Mon Jan 19, 2015 10:07 pm
Post
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! :rockon:

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!
User avatar
Toshiba-3 on Tue Jan 20, 2015 1:50 pm
Post
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:
Code:
          V30      V33
_________________________
vert.: |  2878  |    41 
faces: |    13  |    13

(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!
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Tue Jan 20, 2015 4:58 pm
Post
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.
User avatar
Errol on Tue Jan 20, 2015 6:31 pm
Post
Floating point maths, fantastic stuff :smad:
I read several papers on deduping floating point numbers before giving in and just using C# as my guide.
User avatar
Toshiba-3 on Mon Jan 26, 2015 11:11 pm
Post
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!
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Tue Jan 27, 2015 8:50 am
Post
Ah! :sad: 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 :wink:
User avatar
Toshiba-3 on Tue Jan 27, 2015 12:44 pm
Post
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. :swheel:
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Thu Jan 29, 2015 9:00 am
Post
Quote:
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.

Quote:
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?
User avatar
Toshiba-3 on Thu Jan 29, 2015 11:14 am
Post
Quote:
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 :oops:

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: http://www.toshiba-3.com/dotclear/index ... m-lighting
Image / carmageddon add-ons at road reaction
Pages: 1



Extra information
It is currently Sun Jul 23, 2017 4:44 am,

Please Register a username.
In total there are 3 users online :: 0 registered, 0 hidden and 3 guests
Users browsing this forum: No registered users and 3 guests
Moderators: coffeycup, Toshiba-3

Powered by phpBB :: Hosted by n3wton :: Molested by goats
CWA Links
Facebook