Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SG files and new editing tools
(05-03-2021, 10:51 PM)Pavel 69 Wrote: I mean that you need to check that three points are not collinear https://en.wikipedia.org/wiki/Collinearity

Because it's impossible do determine plane with collinear points, 3d23do program will return error in this case.

I ask this because I know that some papy 3do's have ploygons with more than 4 points. And some points in such polygone may lie on the same line.

Thanks, I understand now. My initial reaction is that I don't think the program will need to do this, because for all the polygons (including those with more than 4 points), it will calculate the ABCD for all possible combinations of the points in the polygon, including those that would be on the same line. If they are on the same line, I believe it will calculate all zeros which will not match with any of the valid ABCDs in the compiled .3do file.

However, this will be a good check to build into a future tool that emulates 3d23do.
Reply
Just checking in with an update. Making slow but steady progress on refinements to the .3DO to .3D tool. Working out some bugs but it is now able to (in a good number of cases) produce a .3D file that is readable with 3D23DO for conversion to .3DO. Although the goal is to still to ultimately create a .3D to "ICR2 3DO" tool, I realize now that the current tool might be useful in a case where you want to bring some ICR2 objects into the N3 format in order to see it in OPE. Or maybe you want to modify a .3DO file in a modded track. Previously, you'd have to use one of those N3 to ICR2 track converters and then unpack the resulting file.

One thing I learned today: a .3D file doesn't like it when you have a function that has a pointer to something that comes after the current row. A compiled .3DO file seems to sometimes scramble the order so I need to code a sorting function to reorder a .3D file to make it readable. This problem seems to occur mostly on the track 3DO files.

Oh, and the MATERIAL function can sometimes be used at the end of a .3D file to refer to the entire model all at once. I didn't know that before - I had thought you needed a MATERIAL function for each POLY [T] but that is not necessarily the case.
Reply
[Image: attachment.php?aid=1782]

I just got my converter to create a Milwaukee .3D file, which I then ran through 3D23DO and created a working .3DO track file (seen here)! Now I am not yet sure if it works in the game or even in OPE, but it's a step!

I also tried Australia and Elkhart Lake, both of which failed to work for some reason, and I need to investigate why.

Edit: Australia works... it seems to be because 3D23DO has a line length limit that was causing an overflow issue. This was particularly a problem in the last LIST and SUPEROBJ but if I broke up those lines, then 3D23DO can read those lines and create a 3DO file properly.


Attached Files Thumbnail(s)
   
Reply
Here's the latest version of the tool, with some examples of .3D files generated by it.

Known issues:
- The DATA near the end of the .3D file should really be put within the preceding LIST function
- It will omit anything after the root. Some ICR2 track.3do files have something after the root for an unknown purpose.
- Sometimes there is a difference between the color in MATERIAL and color of the POLY. I made it default to the color of POLY.
- In certain situations, the MATERIAL GROUP number defaults to 3 instead of figuring out the actual GROUP number if the MATERIAL links to a BSP function or something. Just didn't have time to work on that.


Attached Files
.zip   3dotxt - 5.11.21.zip (Size: 1.06 MB / Downloads: 2)
Reply
Bravo! - I'm not sure I fully can appreciate all of the doors that this will open for us but eventually I'm sure I will.

I would like to get back to track editing but I have needed to change jobs temporarily as I have not been working my regular job due to the semi-conductor crisis going on in the world lately.
Reply
(05-13-2021, 03:21 AM)samsepi0l Wrote: Bravo! - I'm not sure I fully can appreciate all of the doors that this will open for us but eventually I'm sure I will. 

I would like to get back to track editing but I have needed to change jobs temporarily as I have not been working my regular job due to the semi-conductor crisis going on in the world lately.

Lately I haven't had much spare time either, so I've been putting what little time I have into these tools. Just hoping to make the process more streamlined so that it won't take much time for myself or anyone to do track editing.

I'd love to figure out a workflow where I can get from an idea to a drivable track within 20 minutes. That should be manageable for even the busiest people and hopefully bring more modders into the community.
Reply
(05-12-2021, 03:19 PM)checkpoint10 Wrote: Here's the latest version of the tool, with some examples of .3D files generated by it.

Known issues:
- The DATA near the end of the .3D file should really be put within the preceding LIST function
- It will omit anything after the root. Some ICR2 track.3do files have something after the root for an unknown purpose.
- Sometimes there is a difference between the color in MATERIAL and color of the POLY. I made it default to the color of POLY.
- In certain situations, the MATERIAL GROUP number defaults to 3 instead of figuring out the actual GROUP number if the MATERIAL links to a BSP function or something. Just didn't have time to work on that.
- Y ou say that some track.3do files have something after root. Original tracks or new? Because N2toICR2 converter sometime put some text after Header section in 3do file.
- Material string may have color definition? I didn't know that.

Impressive  progress anyway! We waited for such tool far too long Grin3
Reply
Just opened Michigan.3d file. There from _0 to _3168 you can see list of objects. After objects there are strings _3200 - _4556 with LIST functions for drawing order. Like with 3d file after OPE program. So now I can easily add any object to Michigan and place it with correct drawing order. Great!
Reply
Strange, I just went back to try to find an example of the extra bytes after the root (i.e. usually the last flavor in the file, or the first one that the game should call) and I can't find it anymore! As I recall, it looked like an extra Flavor 17 that appeared after the last flavor (usually the Superobj in a track). But it didn't follow the same format as the normal Flavor 17, so I even wrote a little code to prevent the converter from reading it. Maybe I was tired and did something wrong to begin with - a lot of times I am doing this late at night. I will post if I see it again.

Regarding the extra color for the MATERIAL, it appears in the .3do files. For example, if I go back to the old version of what my converter did, you see for example MATERIAL may have a color 178, but it points to a POLY [T] that has color 176. Usually it is off by one or two. I am wondering if maybe each texture has a default color (for example there is only one asphalt texture so there's one default color) but Papy wants to make each track section POLY a slightly different color for the benefit of those people who play without texture.

I haven't done much work with "converted" ICR2 3DOs as I suspect N2toICR2 does not create a 100% similar format as the default tracks. And I am also aware that it inserts text and some junk code to give credit to the converter's author.

You may also notice that I had to reorder all the points to the beginning of the file to ensure they are defined before a POLY line. In a real .3D file generated by TRK23D, the points are embedded in the functions themselves instead of as a named pointer. In a future version of the tool, I can make the tool embed those points as an option, but if you're dealing with simple trackside objects, probably easier to have each point be named for readability.

The greater programming challenge will be to get from the .3D text to ICR2 .3DO, especially the track.3D file which has a lot of functions within functions. My initial thought is to make a tool that processes the .3D file so that each row has only one function. Then it will be more of a straightforward translation to .3DO.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)