Java MDX lib

[oger-lord]

@Dr Super Good
Can you simply explain where I need to make the change in Magos Mdx Specification?
https://github.com/OgerLord/WcDataLibrary/blob/master/src/mdxinfo.txt
After that I can update the code

 

[Dr Super Good]

Can you simply explain where I need to make the change in Magos Mdx Specification?

Under cameras, near "{CameraTargetTranslation}". There is also a "{CameraRotation}" with identifier "KCRL" which is missing and the reason why it breaks cameras.

The structure of this can be found here. It is a track like the others but instead of an array of 3 floats it is a single uint32.

 

[oger-lord]

Under cameras, near "{CameraTargetTranslation}". There is also a "{CameraRotation}" with identifier "KCRL" which is missing and the reason why it breaks cameras.

The structure of this can be found here. It is a track like the others but instead of an array of 3 floats it is a single uint32.

Thanks, added the line to the specification and updated the code.

 

[Dr Super Good]

When loading cameras, the for loop to detect the parts can be made more efficient by breaking if it fails ("else break;") since there is no reason to loop another 2 or so times if it already failed a loop.

 

[Retera]

I'm dropping in with another bug report for the Java MDX Lib that I encountered while using it in my Matrix Eater software: it appears that when parsing FieldOfView, FarClip, and NearClip in Cameras, at least in some circumstances, I was receiving astronomically large and inaccurate values for these fields.

It may be that a simple read/write test produces the same file that was originally read in this case, but accessing and reading the "camera.fieldOfView", "camera.farClippingPlane", and "camera.nearClippingPane" gave me the incorrect and very large values (maybe the float was parsed in the wrong order from the binary?).

Edit: It looks like your library treats this value as an int whereas my MDL library is treating it as floating-point. Perhaps it was meant to be read as a float from the binary?

Another Edit: Switching them to be parsed and saved as floats seems to have fixed the issue in the Matrix Eater codebase.

 

[GhostWolf]

I added all of these fixes in some post on this thread some time ago...just follow the spec.

 

[Retera]

I was going to say that just meant my own repo had gotten out of date with the GitHub repo, but maybe the GitHub one hasn't been updated yet? Looks like it's still using ints for those.

 

[oger-lord]

I'm dropping in with another bug report for the Java MDX Lib that I encountered while using it in my Matrix Eater software: it appears that when parsing FieldOfView, FarClip, and NearClip in Cameras, at least in some circumstances, I was receiving astronomically large and inaccurate values for these fields.

Added the changes to the git repository.

 

[Spacebuns]

Does this mean we can get a modern "upgrade" to the Model Editor which has been around for nearly 10 years, and sometimes doesn't work properly?

 

[Retera]

I think the challenge is one of whether somebody would sit down and write it. I have attached my own "Model Editor", the "Matrix Eater", in one of its newer un-released builds, if you want to take a look.

But the problem is that even my program is something I started in high school that has had new features injected in over several years by just me (one guy). Without either a really, really, dedicated person or a team working together, it would be hard to totally remake all the features of any one of the model editors out there. I have always faced the issue that the Magos Model Editor, the Matrix Eater, and MdlVis all have differing features and to make a complicated model I often need all three of them... which is not so ideal, but hard to correct.

Sidenote: talking about modern software, check out the File > Fetch menu in my attached software. It's a feature I'm particularly proud of; a simple yet elegant way to open model files while thinking in a way that is parallel to the world editor.