Rendition card

[sharangad]

-----------------------------------------------------------------------------
Flavor #4 - MIP Properties Tracks - Objects - Cars
-----------------------------------------------------------------------------
...
Flavor Offset
Call to a Flavor #2, #7, #8 or #11 offset.

Color
This option seems to only affect rendition cards with the anti aliasing
option turned on. Basically flavor 4 outlines the mip with the color that
is specified. ****If the color doesnt match you will have odd miscolored lines
running along polygons.***

So this is what causes the lines with some carsets.

[EDIT] I should be able to fix this in the wrapper by doing something non-standard.

[checkpoint10]

If you are looking to understand the 3DO format, may I also suggest Pavel's guide to writing .3D files (text-based coding for converting into a binary N2/3 or ICR2 3DO file)?
https://www.icr2.net/forum/showthread.ph...91#pid7291

This way you can think about the 3DO commands in a much less abstract way. For example, Flavor #4 is:

<pointer name>: MATERIAL MIP="file name", GROUP=X, <pointer reference>;

[sharangad]

Thanks for that. I've got dat unpacking, mip/mi4 extraction into pngs and resizing working. The carsets load with mostly black or mismapped textures. So the texture coordinates are all that's left. I've written handlers for quite a few flavours and Pavel's guide will help a lot. Been struggling with 3dos for a while. 

That and the mip to mi4 conversion still needs to be done as well.

[sharangad]

One of the things that's been bugging me is that I need to start with 3dos which start with a flavour 16 and drill my way down to everything else. I started off by processing 3dos which contained a modified mip in the headers.

[checkpoint10]

I don't know if this will help. This is my 3do23d converter (i.e. converting ICR2 3DO files to the text 3D file) which at least you can see the names of all the flavors (F16 is SUPEROBJ) and what values they take. This is one way to explore the different 3DOs including the ones for cars. I must warn you that I am only an amateur programmer if even that, and apologies for any bad coding.

https://github.com/skchow03/3do23d

[sharangad]

It's fine. I will use that. It looks like some objects only have flavour 0, which means higher level flavour linking the flavour 0s is missing. Maybe I've messed up somewhere. The headers are the only thing I'm not having problems with. How do you know whether a flavour 0 has texture coordinates? If the first flavour in the file is a 0, how would you know whether text coords are there or not.

The flavours are out of order. So will probably have to be reassembled.

[checkpoint10]

It has been a while, but I'm reading my own code right, I believe my program goes through every POLY and POLY [T] and keeps track of which vertices would have texture coordinates or not, and then at the end it goes and finds the vertices with textures and without.

Also some flavor 0 is NIL and I forget what logic I used to identify those as NIL and not a vertex.

I might've forgotten to link you to Noorok's converter which handles converting N2/3 .3D text files to ICR2 .3DO and his code might be easier to understand. We worked with him to get most flavors in the tool including less common ones.

https://icr2noorok.tumblr.com/post/65603...-converter

[sharangad]

[EDIT] Ignore me, I'm doing silly silly things [/EDIT]
Which version of Python does your script need? I get this:

3do file: c:/dos/crtrack/cars2020/cars2020/mar02.3do
Output .3d file: c:/dos/crtrack/cars2020/cars2020/mar02.3d
Plane matching tolerance: 1
Header size 36
Body size per header 572 vs per file 572
Root offset 556
Reading body...
Traceback (most recent call last):
File "C:\Code\Rendition\DOS (Speedy3D)\ICR23DO\3do23d.py", line 32, in <module>
main()
~~~~^^
File "C:\Code\Rendition\DOS (Speedy3D)\ICR23DO\3do23d.py", line 23, in main
c.convert_3do23d(
~~~~~~~~~~~~~~~~^
filename=args.input_file,
^^^^^^^^^^^^^^^^^^^^^^^^^
...<3 lines>...
combine_data_with_list=args.combine_data_with_list
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "C:\Code\Rendition\DOS (Speedy3D)\ICR23DO\_3do_v2_icr2.py", line 216, in convert_3do23d
body_dict[cur_pos].redef.append((record_num,color))
^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'Recolor' object has no attribute 'redef'

[sharangad]

That's a useful script, thanks to that I've got most of the files processed. A few like camaro.3do still doesn't work:
3do file: C:\DOS\CRTRACK\cars2020\cars2020\camaro.3do
Output .3d file: C:\DOS\CRTRACK\cars2020\cars2020\camaro.3d
Plane matching tolerance: 1
Header size 68
Body size per header 10532 vs per file 10532
Root offset 10488
Reading body...
Identifying vertices
Number of commands in body: 368
Vertices in set: 113
Number of polys = 114
Number of possible poly planes = 831
Finding points for planes at tolerance 1...
No plane match for BSP on offset 8568 (37500000,0,0,515625000000)
No plane match for BSP on offset 6508 (0,421875000,-56250000,-7804687500000)
Plane matching complete with 107 exact matches and 8 approximate matches
Approximate matches have min 0.28819875776397513 and max 0.9555555555555556 difference. Average difference is 0.5755115432820185
Transferring GROUP value from POLY [T] to MATERIAL
MATERIAL at offset 10472 is not directly linked to a POLY [T]. Manual check needed. Group set to 3 by default.
MIP files: ['pacecar']
3DO files: ['sfront', 'helmetp', 'flash2', 'flash1', 'flash3']
PMP files: []
Writing to C:\DOS\CRTRACK\cars2020\cars2020\camaro.3d...done

[checkpoint10]

I think this is showing that the conversion was mostly successful. The exceptions are two BSP statements where it was unable to find vertices within the model that might correspond to the viewing plane. I think the warning about MATERIAL is that for this model, it may be a blanket statement over multiple underlying POLYs, I think I may have seen that before.