LDraw.org Discussion Forums
LDInspector - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: LDInspector (/thread-23882.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14


RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-12

(2020-04-12, 13:01)Stefan Frenz Wrote: The check against additional meta-lines will be included, too.
...just wanted to implement this, but I could not get a complete list of meta lines that are part of the OMR handling itself. In the official OMR model database I found for example the following ones:
Code:
0 !LDRAW_ORG Model
0 !HISTORY 2018-01-08 [bercik] OMR version by Robert Paciorek [bercik] with perrmision of juraj3579
0 !HISTORY 2015-10-28 [Philo] Subparted from Marc Klein initial design
0 //connhole
0 // History:
0 // 2000-05-07 [PTadmin] Official Update 2000-01
0 !KEYWORDS flexible, string, rope
0 UNOFFICIAL PRIMITIVE
0 !HELP Released under a dual license, you can choise "CCAL version 2.0" or "BSD/MIT-type licence":
0 !HELP This material is distributed WITHOUT any warranty, use at YOUR own risk.
0 NOFILE
and many LDCad/TEXMAP specific ones I would always treat as valid like the following ones:
Code:
0 !LDCAD CONTENT [type=spring] [addFallBack=default] [cRes=16] [cResLD=16] [cDia=14] [cRoll=0] [wRes=8] [wResLD=8] [wDia=0.5mm] [wCol=494] [sepMesh=false]
0 !LDCAD GENERATED [generator=LDCad 1.6b]
0 !TEXMAP START PLANAR 0 -34 -255 0 -34 34 0 500 -255 6209851bp01.png
Code:
0 !TEXMAP FALLBACK
Code:
0 !TEXMAP END

So it seems that only 0-lines are invalid, if they don't have "//" or "!" in front? In the above examples, that would be "UNOFFICIAL PRIMITIVE" and "NOFILE"?


RE: LDInspector - Michael Heidemann - 2020-04-12

Hi,
great to see something like this written in Java. Sadfully my Java skills are nearly null I am coding in vb.net.
There is mono out for use net applications under linux. I tried my first application also against mono. But at some point it was so much more effort to also get this running under linux additional to a non existing renderer that I could use also under linux, I did not do any more efforts in this.
Maybe it is just some little tuning necessary today (mono is developing) to get it to work, but I did not remember how I did that.
So I like to help in which way however.

cu
mikeheide


RE: LDInspector - Stefan Frenz - 2020-04-13

(2020-04-12, 20:20)Michael Heidemann Wrote: So I like to help in which way however.
Hi Mike,

thanks for your nice words and helping offer. I looked at MPDCenter to get it running way before this strange idea of writing my own tool for an ecosystem that I surely don't know enough about. I was just playing around with LDraw building some models for OMR and tried to reduce my mistake-frequence... Big Grin

Maybe it would be possible to get the source code of MPDCenter? I would like to try to understand what and how the checks are done there and compare the algorithm against mine. So eventually LDInspector may have some "MPDCenter-mode" with at least similar results. Wink

Best regards
Stefan


RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-13

(2020-04-12, 12:21)Willy Tschager Wrote: The OMRized version of the file above can be found here.
The current LDInspector-version seems to be messed up completely in terms of filenames. Sad  Re-checking the prior working test cases like 31084 OMR just show the same "problem" (but it's root is clearly not in the file but in LDInspector). Seems like the "optimization and refactoring" was too optimistic. Sad

Another question arises: what should be done if the filename contains "-1" like in "31084-1 - xxx" but the inlined parts have prefix without "-1" like "31084 - xxx"? With the coming version, this will be treated as "ok"...?


RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-13

Thanks for pointing at comment metas. In the official OMR database I found the file for 4565 which starts as following
Code:
0 FILE 4565 - main.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 main
0 Name: 4565 - main.ldr
0 Author: Robert Paciorek [bercik]
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 !HELP Copyright (c) 2002-2017, Robert Paciorek (http://www.opcode.eu.org/)
0 !HELP Released under a dual license, you can choise "CCAL version 2.0" or "BSD/MIT-type licence":
0 !HELP Redistribution and use in source or any others forms, with or without modification, ARE PERMITTED provided save information about author(s).
0 !HELP This material is distributed WITHOUT any warranty, use at YOUR own risk.

This completely breaks the current logic of meta handling in LDInspector: all versions up to the current one treat the first non-FILE-meta as description - which in this case leads to "!LEOCAD" instead of "main" as description.

This would not have come to my attention without the meta check. Smile Fixing this will take some more time...


RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-13

In this file there are quite some more interesting lines that I don't understand.
Code:
...
1 14 -80.005 -520 -410.001 -1 0 0 0 1 0 0 0 -1 4565 - station - crane - hook.ldr
1 14 -400 -488 -410 0 0 1 0 1 0 -1 0 0 3492c01.dat

0 NOFILE
0 FILE 4565 - station - crane.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 station - crane
0 Name: 4565 - station - crane.ldr
...
According to the empty line, the "0 NOFILE" meta seems to belong to the following "0 FILE" meta, but as far as I understand the proposal https://forums.ldraw.org/thread-23683.html?highlight=nofile this would "disable" all following file content, for example if binary data is attached (like for an png). But then I don't understand why this meta is included 25 times in a single file and is followed by plain LDraw lines. Additionally, the mentioned sub-file is referenced directly in the main section and therefore should not be skipped.  Huh Now I'm lost completely. Sad

There is another discussion at https://forums.ldraw.org/thread-23762.html?highlight=nofile which suspects combination of "LDCad, MLCad, LPub3D and a texteditor" to be a possible reason for multiple NOFILE metas, but I don't get an idea what LDInspector should do (a) for rendering and (b) for OMR checking. Sad

Can anyone help me with this? Angel   At the time of writing, LDInspector just ignores any "0 NOFILE" comment. With this approach, the rendered image of 4565 seems to be quite valid...


RE: LDInspector version 0.2 - Michael Heidemann - 2020-04-13

(2020-04-13, 9:08)Stefan Frenz Wrote: In this file there are quite some more interesting lines that I don't understand.
Code:
...
1 14 -80.005 -520 -410.001 -1 0 0 0 1 0 0 0 -1 4565 - station - crane - hook.ldr
1 14 -400 -488 -410 0 0 1 0 1 0 -1 0 0 3492c01.dat

0 NOFILE
0 FILE 4565 - station - crane.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 station - crane
0 Name: 4565 - station - crane.ldr
...
According to the empty line, the "0 NOFILE" meta seems to belong to the following "0 FILE" meta, but as far as I understand the proposal https://forums.ldraw.org/thread-23683.html?highlight=nofile this would "disable" all following file content, for example if binary data is attached (like for an png). But then I don't understand why this meta is included 25 times in a single file and is followed by plain LDraw lines. Additionally, the mentioned sub-file is referenced directly in the main section and therefore should not be skipped.  Huh Now I'm lost completely. Sad

There is another discussion at https://forums.ldraw.org/thread-23762.html?highlight=nofile which suspects combination of "LDCad, MLCad, LPub3D and a texteditor" to be a possible reason for multiple NOFILE metas, but I don't get an idea what LDInspector should do (a) for rendering and (b) for OMR checking. Sad

Can anyone help me with this? Angel   At the time of writing, LDInspector just ignores any "0 NOFILE" comment. With this approach, the rendered image of 4565 seems to be quite valid...
This is the source I used for MPDCenter:
https://www.ldraw.org/article/47.html

In MPDCenter the 0 FILE or 0 NOFILE will just tell that a new file inside the mpd content file is starting/ending. Ignoring is not the best option but can result in the same result but it might be different.
cu
Mikeheide


RE: LDInspector version 0.2 - Michael Heidemann - 2020-04-13

(2020-04-13, 9:08)Stefan Frenz Wrote: In this file there are quite some more interesting lines that I don't understand.
Code:
...
1 14 -80.005 -520 -410.001 -1 0 0 0 1 0 0 0 -1 4565 - station - crane - hook.ldr
1 14 -400 -488 -410 0 0 1 0 1 0 -1 0 0 3492c01.dat

0 NOFILE
0 FILE 4565 - station - crane.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 station - crane
0 Name: 4565 - station - crane.ldr
...
According to the empty line, the "0 NOFILE" meta seems to belong to the following "0 FILE" meta, but as far as I understand the proposal https://forums.ldraw.org/thread-23683.html?highlight=nofile this would "disable" all following file content, for example if binary data is attached (like for an png). But then I don't understand why this meta is included 25 times in a single file and is followed by plain LDraw lines. Additionally, the mentioned sub-file is referenced directly in the main section and therefore should not be skipped.  Huh Now I'm lost completely. Sad

There is another discussion at https://forums.ldraw.org/thread-23762.html?highlight=nofile which suspects combination of "LDCad, MLCad, LPub3D and a texteditor" to be a possible reason for multiple NOFILE metas, but I don't get an idea what LDInspector should do (a) for rendering and (b) for OMR checking. Sad

Can anyone help me with this? Angel   At the time of writing, LDInspector just ignores any "0 NOFILE" comment. With this approach, the rendered image of 4565 seems to be quite valid...
As far as I can see you missed some basics.
If a file contains a 0 FILE line it is a mpd content file. If it does not contain a 0 FILE statement it is a plain ldraw file.
mpd content files are created because it was only possible to share your moc if you give all files you used to the next user. If you missed a single file, your model was broken. Just for unofficial or private made parts this was a mess. If we now add a 0 FILE in front of each single file and optional a 0 NOFILE at the end we can just combine those file by adding them (at that time this was done by console statements).
I hope this remembering is not too far away from real creation process Cool


RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-13

(2020-04-13, 18:24)Michael Heidemann Wrote: As far as I can see you missed some basics.
Indeed! Smile  Thanks for helping out, especially the link to the "0 NOFILE" got me out of my messy thoughts. Smile


RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-14

Hi Willy, hi all,

thanks again for your detailed notes.  Smile  Most of them I tried to handle for the current version which is online right now:

(2020-04-08, 11:52)Willy Tschager Wrote: * The installation under win was smooth but you should add a note to the wiki in case the install.bat is stored in the program folder it has to be run with admin privileges.
Done.

(2020-04-08, 11:52)Willy Tschager Wrote: * I'm still confused that something like the Workspace is positioned on the left border and not the items section I work with every day
Modified positioning. My first intention was to guide the new user from left to right in the tool bar, but you are right: most users will be used to have items left.

(2020-04-08, 11:52)Willy Tschager Wrote: * After setting workspace for the first time it should be automatically saved (to <user>\Appdata)at the closing of the dialog.
LDInspector now asks for configuration saving if it was started without configuration. At the moment the save dialog uses the "current directory" and not <user>\Appdata because I like the idea of having something portable. If LDInspector is "installed" on a portable medium like an USB stick, the configuration should go there in my oppinion.

(2020-04-08, 11:52)Willy Tschager Wrote: * I do not like the fact that my file is overwritten right away and that no backup is created. I would prefer a Save button, which saves all the modification at the very end.
I completely rewrote the concept of writing to files. The red buttons now do not overwrite the file, all changes are in memory until you activate "Save" button on the Item pane. This is much better, but I still don't like the current behavior of LDInspector to close or refresh without notice or confirmation if there is unsaved data. This needs some more work...

(2020-04-08, 11:52)Willy Tschager Wrote: * I don't like the order how the checks are presented. A mirrored part to me is secondary, while a correct header is key.
The mirror check is moved downwards and mirrors of the same part only take one line per sub-model, so output flooding as with LS60 in your example should be cured.

(2020-04-08, 11:52)Willy Tschager Wrote: * 0 FILE 364 - Harbour Scene - Warehouse - String.ldr has (among other things a license issue) The quickfix confirmed that a licences has been added but didn't show up in Source. I had to load another subfile and then reload the String to get rid of the error in the OMR-check
* My .mpd will never be OMRized because of: "error: file contains sub-parts, but filename does not end with .mpd"
* Does not update .mpd content after unofficial files have been imported
Double checked these three, but could not reproduce it with my current version.

(2020-04-08, 11:52)Willy Tschager Wrote: * FIlename of imported unofficial files is wrong.
* Complains about filename s\364 - u572p02s01.dat does not start with parent OMR prefix "364 - "
I rewrote most of the code for filename checking and filename generating. Hopefully it is better starting with the current version!  Smile

(2020-04-08, 11:52)Willy Tschager Wrote: * Does not check for: 0 ROTATION CENTER 0 0 0 1 "Custom", 0 ROTATION CONFIG 0 0
I added a quick check for "unexpected" metas, but it only showed that I didn't understand the LDraw file format, yet.  Sad  So the current version does some checks, but the checks are not valid at the moment - instead they prove invalid file reading by the LDInspector LDraw parser. Especially unexpected meta lines before the description meta, but also even before the author meta breakes LDInspector edit code:

Code:
0 FILE 4565 - station - crane.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 station - crane
0 Name: 4565 - station - crane.ldr
This breakes because LDInspector requires the first non-file-meta to be the description at the moment, so "!LEOCAD" is taken as description by accident. Even worse, the name tag is not written back correctly because my understand until last week  Blush  was that the header lines are always fixed. My only source of LDraw models is LDCad, which generates only very nice files. Smile Additionally, reading the article https://forums.ldraw.org/thread-23904.html makes me thinking of re-writing the case-sensitivity of my parser. Sad  I know, the file format is "grown historically", but making a difference between "0 FILE" and "0 File" depending on existence of other metas does not make me feel happy.

This leads to another substantial question: at the moment, LDInspector does only minimal change, i.e. writing a file will keep as many original lines as possible. Even correctly parsed files are not completely rebuild from the parsed structure but original source code will be inserted - for example to avoid floating point precision loss and to keep intentional formatting or comments. But with all those "special quirks" (with my understanding of last week) at least the meta handling has to be re-done. Even if all LDraw software would produce such nice files as LDCad does - "old files" should work with LDInspector, too. I would like to do the header parsing again, but at the moment I feel that I still don't understand all meta considerations.

Long story short: I will test some more officially released OMR files, but Willy's hint to un-OMR-ized 364 was extremely helpful. Smile  So if you have non-LDCad-files that should be "ok" or have still known issues and that break LDInspector in some way, they most likely will be very helpful, too.

Thanks for all your feedback helping me on my way towards LDInspector 0.3...  Wink