[LDPartEditor] 0.8.24 Beta Released (Rounding per X,Y,Z / bugfix)

[LDPartEditor] 0.8.24 Beta Released (Rounding per X,Y,Z / bugfix) - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: Parts Author Tools (https://forums.ldraw.org/forum-24.html)
+--- Thread: [LDPartEditor] 0.8.24 Beta Released (Rounding per X,Y,Z / bugfix) (/thread-21746.html)

[LDPartEditor] 0.8.24 Beta Released (Rounding per X,Y,Z / bugfix) - Nils Schmidt - 2016-09-03

Hey,

here is version 0.8.24 with 4 bug fixes and 3 enhancements.
...I am writing content for the wiki/manual now.

As always, you can download LDPE from this page:
http://nilsschmidt1337.github.io/ldparteditor/

Changelog:
(3 new features and 4 bug fixes)

With this release you will be able to...

...use per-component rounding (X, Y, Z) instead of the per-vertex rounding (useful for patterns on slopes).
...use the metadata dialog (AKA "header dialog") on the text editor, too.
...benefit from a faster program start.

The following critical issues were fixed:

It was not possible to activate "Create a new conditional line..." via a shortkey.
The new LDU to stud converter did not round correctly (20 LDU = 1 stud, rounded to one decimal place)
The Merge/split->Set X,Y,Z window appears only with a single vertex selection, it no longer works on a multiple selection (eg. to snap a selection on a plane).
The error message "Invalid use of 'BFC INVERTNEXT' / Flat subfile" got duplicated.

What will the next release 0.8.25 deliver? Bug fixes, more header validation features, usability improvements...

The program was tested intensively with "real world" files.
However, it is still a beta version and something can go wrong in about 100.000 lines of code.

Make sure that you choose the right architecture for your OS and Java Virtual Machine (JVM) (64bit or 32bit).
A short guide how to check if a 64bit JVM is installed on your system is located at the bottom of this message.

Download the zip-Archive
Extract the archive content to the location of your choice
On windows, double-click "run.bat" to start LDPE.
On linux/mac, you have to excecute the shell script "run.sh" to start LDPE.

Please note that this software is in the beta stage. Although, LDPE 0.8.24 was tested, there are already known issues for this release. There is a potential risk of data loss.

You can search for updates if you do the following steps:

On windows, double-click "update.bat" to search for updates.
On linux/mac, you have to excecute the shell script "update.sh".

I listen carefully to your requests and possible complaints. Please leave me a message, with your thoughts and wishes to further improve the software.

LDPE is a 3D CAD application: The overall system requirements are higher. While I recommend to use a powerful 64-bit multicore system, it could be possible, to run LDPE on older machines as well.

System Requirements:

Minimum System Requirements:

Java Runtime Environment (JRE) 1.8
OpenGL 2.1 compatible Graphics Card
Operating System (32/64bit): Windows [XP; Vista; 7 or newer], Mac OS X [>=10.6], Linux [e.g. Ubuntu Linux >=10.4]
CPU: Multicore-Processor e.g. Intel Core 2 Duo or AMD Athlon II (>2.0Ghz)
RAM: 4GB
Video-Memory: 512 MB
Free Disk Space: 100 MB

Recommended Requirements:

Operating System (64bit): Windows 7, Mac OS X [>=10.6], Linux [e.g. Ubuntu Linux >=10.4]
CPU: Multicore-Processor with 4 cores (or more)
RAM: >4 GB
Video-Memory: >=1 GB
Free Disk Space: 512 MB

--------------------------------------------------------------------------------
How to check your JVM version (32- or 64-bit):
--------------------------------------------------------------------------------

You can try on the command line:

java -d64 version

If it's not a 64-bit version, you'll get a message that looks like:

This Java instance does not support a 64-bit JVM. Please install the desired version.

In general, I recommend to install the 64-bit version of the JVM for Java 8.

RE: [LDPartEditor] 0.8.24 Beta Released (Rounding per X,Y,Z / bugfix) - Philippe Hurbain - 2016-09-03

(2016-09-03, 11:07)Nils Schmidt Wrote: The Merge/split->Set X,Y,Z window appears only with a single vertex selection, it no longer works on a multiple selection (eg. to snap a selection on a plane).

Thanks

[LDPartEditor] Merge/split->Set X,Y,Z / negative value entry - Philippe Hurbain - 2016-09-07

Wishes of the day...

Very, very often when I use Merge/split->Set X,Y,Z function I end up collapsing all vertices to a single point because I forget to uncheck 2 coordinates...
- As a user, I'd like that all three coordinates be unchecked when this dialog opens. Ideally, the coordinates where I type in a value should become active.

It is difficult to type in values in all dialog windows.
- As a user, I want to be able to type in negative value easily. If I key in 12.54, I get the correct value. If I key in -12.54, I get 1.2.54 (two times wrong since "value" is positive, and with extra decimal separator). (major issue)
- As a user, I'd like that existing value becomes selected when I click in a field, ready to be wiped out. of course, clicking again at some position in the field should place the insertion cursor there. (annoying but I can live with this...)
- As a user, I'd like to be able to key in .54 instead of 0.54 (this one is really minor!).

Selection of values in text window could be improved too...
- As a user I'd like double click on a decimal number to select the whole value, including integer part, decimal part, decimal separator and minus sign if any.

RE: [LDPartEditor] Merge/split->Set X,Y,Z / negative value entry - Nils Schmidt - 2016-09-07

I created a bunch of issues for these wishes...
Guess you'll get #439 and #440 with the next release.

Nevertheless, I am busy writing wiki content in the evening :)

RE: [LDPartEditor] Merge/split->Set X,Y,Z / negative value entry - Philippe Hurbain - 2016-09-08

Quote:I created a bunch of issues for these wishes...
Guess you'll get #439 and #440 with the next release.

Nevertheless, I am busy writing wiki content in the evening

Thanks! For my enlightenment, what's the meaning of "Epic" tag for " Improve all DecimalSpinner widgets #441"? that the struggle to do the improvement will be epic? Wink

Otherwise, nice icons for wiki chapters Wink

RE: [LDPartEditor] select/connected quirks - Philippe Hurbain - 2016-09-08

Quirk report of the day (dunno if these should be considered as bugs...)
- Two elements are considered as connected even if they share only a single vertex. I think they should be considered as connected only if they share at least an edge.
- If I uncheck lines in selection filter, perform a select/connected and hit del, connected lines are nonetheless deleted, but if I move selection lines stay at their initial position. To get the behaviour I expect I have to uncheck vertices too in selection filter.

RE: [LDPartEditor] 0.8.24 Beta Released (Rounding per X,Y,Z / bugfix) - Philippe Hurbain - 2016-09-08

Quote:The Merge/split->Set X,Y,Z window appears only with a single vertex selection, it no longer works on a multiple selection (eg. to snap a selection on a plane).

Looks like this issue is not completely cleared... After "some time" using LDPE, the Merge/split->Set X,Y,Z window refuses to open on a multiple selection again. I guess that I do something that modifies LDPE state, and from then on, Merge/split->Set X,Y,Z stops working. Close/reopen file does not cure the issue, the only way I found is to completely shut down LDPE. Unfortunately, though it happened 3 times, I was not able to determine the trigger for this behaviour Sad

Edit: got it again, doesn't work even for a single vertex.
Error log attached, maybe it can help... Edit: seems to be related to the null pointer exception.

Workaround for broken "Set X,Y,Z" - Nils Schmidt - 2016-09-08

(2016-09-08, 12:59)Philippe Hurbain Wrote:
Quote:The Merge/split->Set X,Y,Z window appears only with a single vertex selection, it no longer works on a multiple selection (eg. to snap a selection on a plane).
Looks like this issue is not completely cleared... After "some time" using LDPE, the Merge/split->Set X,Y,Z window refuses to open on a multiple selection again. I guess that I do something that modifies LDPE state, and from then on, Merge/split->Set X,Y,Z stops working. Close/reopen file does not cure the issue, the only way I found is to completely shut down LDPE. Unfortunately, though it happened 3 times, I was not able to determine the trigger for this behaviour

Edit: got it again, doesn't work even for a single vertex.
Error log attached, maybe it can help... Edit: seems to be related to the null pointer exception.

Thanks! This crazy bug was also present in older versions of LDPE.
I was able to reproduce the null pointer exception with the following steps:

Open a file with LDPE
Select one triangle and copy it to the clipboard
Select anything
Try to open Merge/split->Set X,Y,Z

Temporary workaround: Copy more than one object to the clipboard before you use Merge/split->Set X,Y,Z.

RE: Workaround for broken "Set X,Y,Z" - Philippe Hurbain - 2016-09-08

Quote:Temporary workaround: Copy more than one object to the clipboard before you use Merge/split->Set X,Y,Z.

Thanks

Glad you spotted the problem!

What is "epic"? - Nils Schmidt - 2016-09-08

(2016-09-08, 7:03)Philippe Hurbain Wrote:
Quote:I created a bunch of issues for these wishes...
Guess you'll get #439 and #440 with the next release.

Nevertheless, I am busy writing wiki content in the evening
Thanks! For my enlightenment, what's the meaning of "Epic" tag for " Improve all DecimalSpinner widgets #441"? that the struggle to do the improvement will be epic?

Otherwise, nice icons for wiki chapters

I solved #439, #440 and #442 by the way! But I digress...

Yes and no Big Grin

"epic" means something else:

Quote:An Epic can be defined as a work, which can not be completed in a week time, or any work which will take a full release cycle to complete. By observation 5-10 user stories comprise of one Epic in agile methodology.

In this case, I have to completely re-design the decimal spinner logic which is not done in one day.
Normally, I will create a draft on a piece of paper first and then I will define all tasks and stories which are required to solve the problem.

OpenGL 3 (and Vulkan) Render Path - Nils Schmidt - 2016-09-09

Hi,

I just want to drop a note that I will implement a second render path for modern OpenGL 3.
I already implemented some provisions for OpenGL 3 support.
Currently, LDPE uses only the legacy OpenGL 1.0 and 2.0 API (which is now deprecated since 8 years).

This means that I will maintain two render paths to support both, old and modern hardware.
I will also try to make use of OpenGL 4.5 and Vulkan, but OpenGL 3 has now the highest priority.

As a end-user, you don't have to learn anything new. The "look and feel" will stay the same.
I guess the overall performance will increase by a huge amount.

Leg godt,

Nils

OpenGL 3.3 Core Migration (First Impressions) - Nils Schmidt - 2016-09-14

Hey,

here is a first impression from the new render path.
I have to replace every function which draws a 3D object onto the screen, but the effort will be worth it.
The new render path will be included in the next release 0.8.25. It didn't make it due to limited free time...

[Image: OpenGL3_3_Screenshot1.PNG]

RE: [LDPartEditor] Problems with condlines/flipper tool - Philippe Hurbain - 2016-09-19

Flipper doesn't properly recalculate control points of condlines adjacent to a flipped triangle pair: see image. Left, mesh before flip of the two grey triangles with an adjacent condline highlighted. Middle, after flip, this condline is wrong. Right: what it should be.
Edger 2 puts condlines/edge lines between surfaces and... protractors!!! (a really, really minor one )

RE: [LDPartEditor] Problems with condlines/flipper tool - Nils Schmidt - 2016-09-19

(2016-09-19, 9:06)Philippe Hurbain Wrote:
Flipper doesn't properly recalculate control points of condlines adjacent to a flipped triangle pair: see image. Left, mesh before flip of the two grey triangles with an adjacent condline highlighted. Middle, after flip, this condline is wrong. Right: what it should be.

Edger 2 puts condlines/edge lines between surfaces and... protractors!!! (a really, really minor one )

Thanks! Now I am able to fully understand the flipper problem Smile

I can't promise that it will be fixed with version 0.8.24.

As I said, currently, I do implementing a modern (and complex) OpenGL render path.
My recent benchmark result was a frametime of 5ms for a 50 x 50 baseplate (200 FPS).

The old implementation needs 105 to 200ms for a single frame (5-10 FPS) on my machine.
The new implementation is about 20-40 times faster than the old one.
I am not done yet...

The current work on LDPE "slows me down" a little bit.
Doing this high-performance OpenGL coding is similar to rocket science.
Maybe I release 0.8.24 first and delay the integration of this big feature? (this will likely happen).
Although I still make progress...

RE: [LDPartEditor] Problems with condlines/flipper tool - Philippe Hurbain - 2016-09-19

Quote:The new implementation is about 20-40 times faster than the old one.

Wow! I hope that my somewhat outdated hardware will be able to use this!

RE: [LDPartEditor] Problems with condlines/flipper tool - Magnus Forsberg - 2016-09-19

(2016-09-19, 15:23)Nils Schmidt Wrote: frametime of 5ms for a 50 x 50 baseplate

How fast will it be if you, like I've done, add a 3D-logo to my stud.dat file? I use my own file, logo5.dat.
This makes me have to turn on lo-res studs in Ldview, when I open or work on a large model or baseplate.

RE: [LDPartEditor] Problems with condlines/flipper tool - Nils Schmidt - 2016-09-19

(2016-09-19, 15:48)Magnus Forsberg Wrote: How fast will it be if you, like I've done, add a 3D-logo to my stud.dat file? I use my own file, logo5.dat.
This makes me have to turn on lo-res studs in Ldview, when I open or work on a large model or baseplate.

Well, unfortunately it is not that easy. LDPE will try to load the arbitrary vertex and adjacency data from logo5.dat into the system memory. The whole file tree, with lots of redundant and superflous data...
I have ideas to reduce the memory footprint, but this kind of cheating contradicts with the current design idea to represent the LDraw part file tree as close and as accurate as I can...
The loading process took more than 10GB of my system RAM... and then it failed to generate some data to render...
But I was able to load four stug-16x16.dat stud groups instead and it was rendered with a frametime of 30ms. I did not enable backface culling.

TL;DR You cannot use hundreds of logo5.dat high-res studs with LDPE. It will load the model with every grain of data it may contain. Every vertex and all its connection info... and this will eat all system resources.

There is already an option to display the stud logo. I may integrate HQ stud versions in the future...

RE: [LDPartEditor] Problem with Edger2 "precision" - Philippe Hurbain - 2016-09-21

Magnus and myself suspected a problem with LDPE built in Edger2 - looks like I finally found it!
It seems that Edger2 only creates condlines if the adjacent surfaces vertices match perfectly. Even a minute discrepancy prevent creation, and this regardless of the value of "precision" field.
Workaround: run unificator first (this may fail if there are slightly mismatched primitives)

RE: [LDPartEditor] Problem with Edger2 "precision" - Nils Schmidt - 2016-09-21

(2016-09-21, 18:54)Philippe Hurbain Wrote: Magnus and myself suspected a problem with LDPE built in Edger2 - looks like I finally found it!
It seems that Edger2 only creates condlines if the adjacent surfaces vertices match perfectly. Even a minute discrepancy prevent creation, and this regardless of the value of "precision" field.
Workaround: run unificator first (this may fail if there are slightly mismatched primitives)

Thanks! I created an issue.

RE: [LDPartEditor] wrong collinear detection threshold? - Philippe Hurbain - 2016-09-23

The attached file (excerpt from http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/4162p14.dat) has a quad reported as collinear by LDPE. Checking angles with protractor shows that the most offending angle is 179.34°, well below the [/url][url=http://www.ldraw.org/article/512.html#colinear]specification limit of 179.9°

RE: [LDPartEditor] last added elements not saved. - Philippe Hurbain - 2016-09-23

A bug I reported a long time ago (but I don't find it again in the forum) tha't still bugging me...

Elements added just before saving file are NOT recorded.
Reproducing it: open new.dat in 3d editor, add a bunch of triangles/lines/primitives. Do nothing else, then save file. Resulting file only contains header.
Workaround: hit undo/redo before saving.

RE: [LDPartEditor] last added elements not saved. - Nils Schmidt - 2016-09-23

(2016-09-23, 7:51)Philippe Hurbain Wrote: A bug I reported a long time ago (but I don't find it again in the forum) tha't still bugging me...

Elements added just before saving file are NOT recorded.
Reproducing it: open new.dat in 3d editor, add a bunch of triangles/lines/primitives. Do nothing else, then save file. Resulting file only contains header.
Workaround: hit undo/redo before saving.

I was able to reproduce the bug. I will fix this asap with the release of 0.8.25.

edit: I fixed it.

RE: [LDPartEditor] last added elements not saved. - Philippe Hurbain - 2016-09-23

Quote:edit: I fixed it.

9 minutes is a great time Wink

RE: [LDPartEditor] wrong collinear detection threshold? - Nils Schmidt - 2016-09-23

(2016-09-23, 7:28)Philippe Hurbain Wrote: The attached file (excerpt from http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/4162p14.dat) has a quad reported as collinear by LDPE. Checking angles with protractor shows that the most offending angle is 179.34°, well below the specification limit of 179.9°

This is interesting...
In this case, LDPE calculates the wrong angle, but nevertheless, I would split this quad into two triangles ;)
I doubt that I am able to correct this to clone the exact behaviour of LDDP or Datheader.
I tried a few things to change the angle calculation, but none of them gave me "better" results.

As long as LDPE does not allow values above the specification limit I might be free to leave it as it is.
Numerics..., what else could I say... :D

Wrong line is added in the text editor - Magnus Forsberg - 2016-09-23

I sometimes experience a strange bug, using Ctrl-C and Ctrl-V

Select and copy line A using Ctrl-C
place the cursor at the place in the text editor were I want it to be. Use Ctrl-V
Line A is added
do some more editing
select and copy a new line B
place the cursor at the place in the text editor were I want it to be. Use Ctrl-V
LDPE adds line A in the text editor, not as expected line B
delete the bad line A
select and copy line B again
place the cursor at the place in the text editor were I want it to be. Use Ctrl-V
Line B is added

It doesn't happen all the time, so I think there must be something else involved, but I can't put my finger on it.

RE: [LDPartEditor] wrong collinear detection threshold? - Philippe Hurbain - 2016-09-23

(2016-09-23, 14:38)Nils Schmidt Wrote: This is interesting...
In this case, LDPE calculates the wrong angle, but nevertheless, I would split this quad into two triangles
I doubt that I am able to correct this to clone the exact behaviour of LDDP or Datheader.
I tried a few things to change the angle calculation, but none of them gave me "better" results.

As long as LDPE does not allow values above the specification limit I might be free to leave it as it is.
Numerics..., what else could I say...

Clearly this issue won't prevent me from sleeping! But I fail to understand why LDPE is able to calculate the right angle value for protractor but not for collinearity check ?!?

RE: [LDPartEditor] wrong collinear detection threshold? - Nils Schmidt - 2016-09-24

(2016-09-23, 17:29)Philippe Hurbain Wrote: Clearly this issue won't prevent me from sleeping! But I fail to understand why LDPE is able to calculate the right angle value for protractor but not for collinearity check ?!?

Well, I took a deeper look and have to admit that LDPE's collinearity detection for quads is not compliant to the file format restrictions for the official library...
I created an issue for this.
Let me explain why:

Normally, you would calculate the inner angles of the quad to detect collinearity.
However, in 2012, I decided to do some things different and I calculated the angles relative to the point D.
I also computed the diagonal vector DB for some reasons I do not understand.
The current implementation detects collinearity somehow, but it does not detect if an interior angle is not between 0.025° and 179.9°!
This is hilarious! I will correct this ;)

[Image: d2da076e-8259-11e6-9868-351fba1b4e3c.PNG]

[Image: d2da076e-8259-11e6-9868-351fba1b4e3c.PNG]

RE: [LDPartEditor] wrong collinear detection threshold? - Philippe Hurbain - 2016-09-24

Quote:This is hilarious! I will correct this

I see you have a good sense of humor Big Grin

RE: [LDPartEditor] Hide/unhide from text editor - Philippe Hurbain - 2016-09-25

Wish of the day (maybe I missed an existing feature?):
- I'd like to be able to hide/unhide things from the text editor.
- I'd like to be able to know (in text editor) which lines are currently hidden (Might be text written in italic, or in grey color).

RE: [LDPartEditor] Hide/unhide from text editor - Magnus Forsberg - 2016-09-25

Me too.

RE: [LDPartEditor] 0.8.24 Beta Released (Rounding per X,Y,Z / bugfix) - Willy Tschager - 2016-09-26

Bug of the day:

* LDPE warns about his own meta (NOT KIDDING):

* The prim you see below the metas doesn't get rounded. Actually rounding doesn't work at all.

Feature request of the day:

* As a user I'D like to have the triples of "protractor" and "distance" as well as the color digit colored

w.

RE: [LDPartEditor] 0.8.24 Beta Released (Rounding per X,Y,Z / bugfix) - Philippe Hurbain - 2016-09-26

Quote:* LDPE warns about his own meta (NOT KIDDING):

Actually I like a lot this feature, as it is a way to rapidly get rid of construction thingies when the part is completed (thanks to "quick fix")

Rounding doesn't work? (Text Editor) - Nils Schmidt - 2016-09-26

(2016-09-26, 6:32)Willy Tschager Wrote: Bug of the day:

* The prim you see below the metas doesn't get rounded. Actually rounding doesn't work at all.

"Single Vertex Modification" (aka SyncEdit) is on... you have to press the SyncEdit button (or the ESC key) to cancel it.
When SyncEdit is on, rounding will only work with the activated vertex.

RE: [LDPartEditor] Problem with Edger2 "precision" - Nils Schmidt - 2016-09-26

(2016-09-21, 18:54)Philippe Hurbain Wrote: Magnus and myself suspected a problem with LDPE built in Edger2 - looks like I finally found it!
It seems that Edger2 only creates condlines if the adjacent surfaces vertices match perfectly. Even a minute discrepancy prevent creation, and this regardless of the value of "precision" field.

Ok, I tried different settings with "precision" values from 0.01 to 1.00 and I was not able to reproduce this problem... :(

RE: [LDPartEditor] Problem with Edger2 "precision" - Philippe Hurbain - 2016-09-27

I couldn't either Sad

Hopefully I'll be able to find again the original file where this occured (it was while building this part http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/24947.dat). But trying to reproduce this problem, I stumbled on another one: LDPE edger2 wrongly adds condlines in the middle of slightly warped quads (here 1.36°):

Code:
4 16 5.5434 24 -2.2962 9.2079 20.0834 -4.1575 10.1608 20.0834 0 6 24 0

4 16 10.1608 20.0834 0 9.2079 20.0834 4.1575 5.5434 24 2.2962 6 24 0

RE: [LDPartEditor] Problem with Edger2 "precision" - Philippe Hurbain - 2016-09-27

So... maybe it's not a general problem, but here is a buggy case. LDPE Edger2 with default settings generates unmatched lines everywhere (****). With increased precision value (from 0.001 to 1), no unmatched line is created between quads (so precision parameter does have an influence)... but no condline either!
(****) Default precision value of LDPE Edger2 is 0.0001, which is pretty low. Regular Edger2 default is 0.001, a value validated by years of usage...

RE: [LDPartEditor] Problem with Edger2 "precision" - Nils Schmidt - 2016-09-27

(2016-09-27, 18:46)Philippe Hurbain Wrote: (****) Default precision value of LDPE Edger2 is 0.0001, which is pretty low. Regular Edger2 default is 0.001, a value validated by years of usage...

Thanks for the info! The default value is now 0.001.
And I just updated issue #453...

I am going to release 0.8.25 in a few minutes! :)

RE: [LDPartEditor] Problem with Edger2 "precision" - Philippe Hurbain - 2016-09-28

Quote:Thanks for the info! The default value is now 0.001.

The first time I checked I micounted the 0 and thought both used the same value Wink

Quote:And I just updated issue #453...

Thanks!
Looks like you missed my condline-in-quad bug report here: http://forums.ldraw.org/thread-21746-post-23290.html#pid23290

Quote:I am going to release 0.8.25 in a few minutes!

Thnaks for this too Wink