[LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)

[Nils Schmidt]

Hey,

a new release with dozens of fresh features and three bug fixes for Windows, Linux and Mac


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

Changelog:
(11 new features and 3 bug fixes)

With this release you will be able to...

• ...benefit from better decimal spinner widgets.
  
• ...make use of a "Select All Types" and a "Select Nothing" menu item along with Vertices, Lines, Triangles, etc.
  
• ...use "Show All" in the context menu from the text editor
  
• ...use a shortkey to swap the BFC winding of a selection ("J" key).
  
• ...see where the distance meter starts.
  
• ...see where the protractor is fixed.
  
• ...use the selection filter to control the element types which are inserted by copy & paste
  
• ...use the selection filter to control which element types are selectable.
  
• ...see tooltips which explain that ALT+Click removes the corresponding object type from selection when you activate Vertex/Surface/Line/Subfile Mode
  
• ...benefit from better performance if you have a large number of hidden objects.
  
• ...benefit from the fact that the primitive area is reset to the top left corner on load.
  

The following critical issues were fixed:

1. Selection got cleared while using the subfile mode.
   
2. Wrong number format for the "Stud" in the unit converter.
   
3. Snap on edges: The projection was incorrect.
   

What will the next release 0.8.36 deliver? Select elements which producing an error in 3D editor...

---

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.

1. Download the zip-Archive
   
2. Extract the archive content to the location of your choice
   
3. On windows, double-click "run.bat" to start LDPE.
   
4. 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, this version 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:

1. On windows, double-click "update.bat" to search for updates.
   
2. On linux, 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:

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

Recommended Requirements:

• Operating System (64bit): Windows 7,8,10, Linux [e.g. Ubuntu Linux >=14.4], Mac OS X [>=10.6]
  
• OpenGL 3.3 compatible Graphics Card
  
• CPU: Multicore-Processor with 4 cores (or more)
  
• RAM: >4 GB
  
• Video-Memory: >1 GB
  
• Free Disk Space: 512 MB
  
• For a faster start, LDPartEditor and the LDraw™ library should be installed on an SSD.
  

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

You can try on the command line:

Code:

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.

[Philippe Hurbain]

Eager to test it... Unfortunately not before several days!

[Nils Schmidt]

Eager to test it... Unfortunately not before several days!

No problem!

[Magnus Forsberg]

Can't really pinpoint why, but I'm experiencing some sort of lag between selection and the visualization of the selected item.
It was already present in the former version, so it's not something new in 0.8.35. It suddenly disappeared when I was working, but I can't seem to repeat the behavior. Hm..

[Magnus Forsberg]

... I'm experiencing some sort of lag between selection and the visualization of the selected item.

I think this issue is connected to the button "split quad into triangles". One time, the lag dissapered after I clicked on that button.

...use the selection filter to control which element types are selectable.

I don't like/understand this feature. If I on the Selection-meny turn off one, or some, of the filters, the buttons for choosing vertex/surface/line becomes useless/inactivated. The buttons are only useable when I have all filters selected.

How is it supposed to work? If I only select Line-filter, and then click on a edge, it gets selected, if the Line-button is activated. I then want to select all connected edges and choose Select connected, every edge in the file gets selected except edges in primitives. To get what I want, I have to also choose ...with same colour.


...as a user I want the hover over right click meny-icon to be placed somewhere else. Or that it closes again when I hover outside that meny. I don't like that it opens when I accidentally pass over it. It stays open untill I click on something, forcing me to click twice, once to close that meny, and a second time to choose want I intended to do.

[Nils Schmidt]

...use the selection filter to control which element types are selectable.

I don't like/understand this feature. If I on the Selection-meny turn off one, or some, of the filters, the buttons for choosing vertex/surface/line becomes useless/inactivated. The buttons are only useable when I have all filters selected.

How is it supposed to work? If I only select Line-filter, and then click on a edge, it gets selected, if the Line-button is activated.

I fixed this issue today, I didn't like this feature, too (#579).

As a user I want the hover over right click menu-icon to be placed somewhere else.

I created an issue (#580).

Select connected, every edge in the file gets selected except edges in primitives. To get what I want, I have to also choose ...with same colour.

Edges in primitives are not generally connected to the mesh. The coordinates may differ sometimes, depending on the transformation matrix of the primitive.

[Magnus Forsberg]

Edges in primitives are not generally connected to the mesh.

Problem isn't edges in primitives, It's that all edge-lines are selected, even if there is no edge-line between two groups of edge-lines. Only connecting surfaces.
Select only filter Lines. Try inlining a 4-4cylo down to edges and surfaces. Remove all cond-lines. Select a single edge-line in one of the two rings of edges. Select Connected, and both groups of edges gets selected. If I add 'with same colour' only one group is selected.


The automagic rounding of moved stuff doesn't work properly. Vertices get a very small positive or negative error added in x or z direction, never in y direction. Sometimes half the moved group of stuff get auto-rounded, and the other don't. I sometimes see stuff getting auto-rounded only after they are deselected. It's as if selected items are prevented from being auto-rounded.


Rectifier:

• There is no difference in the result on the fourth filter. "Convert if possible/Do not convert if adjacent cond-line." I have to comment out all affected cond-lines in order to create more rect-prims.
  

Text-editor:

• If I hit the Save-button twice, the button stays in 'down'-position.
  
• Why do the cursor jump to the first line when I hit 'Save'? I work with the 'Insert after cursor' activated and don't like to find stuff added in the header after a Save.
  

[Nils Schmidt]

The automagic rounding of moved stuff doesn't work properly. Vertices get a very small positive or negative error added in x or z direction, never in y direction. Sometimes half the moved group of stuff get auto-rounded, and the other don't. I sometimes see stuff getting auto-rounded only after they are deselected. It's as if selected items are prevented from being auto-rounded.

How can I reproduce this?

[Nils Schmidt]

Rectifier:

• There is no difference in the result on the fourth filter. "Convert if possible/Do not convert if adjacent cond-line." I have to comment out all affected cond-lines in order to create more rect-prims.
  

Thanks, I was able to find the root cause for this issue (#582). I will fix it with the next release.

[Nils Schmidt]

Problem isn't edges in primitives, It's that all edge-lines are selected, even if there is no edge-line between two groups of edge-lines. Only connecting surfaces.
Select only filter Lines. Try inlining a 4-4cylo down to edges and surfaces. Remove all cond-lines. Select a single edge-line in one of the two rings of edges. Select Connected, and both groups of edges gets selected. If I add 'with same colour' only one group is selected.

"Select connected with same colour" works as it should.
It collects all colours from the original selection and checks then, which objects of the same colour are directly adjacent to the original selection. This will be repeated until no new objects are added to the selection.

"Select connected" will always check connected surfaces, too, if there are no additional conditions active.
It is the most general case for a connected selection. I have bad feelings to limit its default funtionality, since both selection variants have its benefits.

Maybe, you need a "...with same type." option? This will be very easy to implement. I created an issue (#584).

[Willy Tschager]

Bug of the day:

* I'm irritated by the fact that the 3D editor places the tab of a newly opened part on the left of an already opened part, while in the text editor it is placed as expected on the right.

w.

[Magnus Forsberg]

How can I reproduce this?

I had to think about this and retrace my workprocess.

It seems to be possible to introduce an 'invisible' error into the entry-fields Move/Rotate/Scale menues.
It looks like there are only 8 decimals after the comma, but it is possible to place the cursor at the 'visible' end, and add a digit. When I then click somewhere else that digit dissapears from the view. I thought: OK, nothing happend. But that extra, invisable digit, can create a chainreaction that show up after a few futher movements of vertices, as a rotation error.

How many digits are actually stored from the entry fields? Why so many decimals after the comma?
If I want to rotate something 11.25 degrees, and not 11.25000000000000001 degrees, all I need is two decimals.

[Nils Schmidt]

It seems to be possible to introduce an 'invisible' error into the entry-fields Move/Rotate/Scale menues.
It looks like there are only 8 decimals after the comma, but it is possible to place the cursor at the 'visible' end, and add a digit. When I then click somewhere else that digit dissapears from the view. I thought: OK, nothing happend. But that extra, invisable digit, can create a chainreaction that show up after a few futher movements of vertices, as a rotation error.

I created an issue (#585).
When I am done implementing this, you will see a warning sign if the displayed value differs from the value which is actually stored inside the entry-field.

How many digits are actually stored from the entry fields? Why so many decimals after the comma?
If I want to rotate something 11.25 degrees, and not 11.25000000000000001 degrees, all I need is two decimals.

About 24 digits are stored. The entry field is capable of arbitrary precision.

[Magnus Forsberg]

Bug of the day:

* I'm irritated by the fact that the 3D editor places the tab of a newly opened part on the left of an already opened part, while in the text editor it is placed as expected on the right.

w.

While your at it:
A click on the red close-cross in the text-editor, closes only that tab in the text-editor.
A click on the red close-cross in the 3D-editor, closes both tabs, in 3D and text-editor.

[Willy Tschager]

While your at it:
A click on the red close-cross in the text-editor, closes only that tab in the text-editor.
A click on the red close-cross in the 3D-editor, closes both tabs, in 3D and text-editor.

+1

[Philippe Hurbain]

+1 too. For me, the desired behavior would be to close file in both text and 3d.

[Philippe Hurbain]

As it has been mentionned recently a few times, there are many cases where vertices that should match perfectly do not, because they belong to different primitives/subparts, and rounding in these files make them slightly different. This is annoying for two things:
- selection doesn't extend past these slight mismatches (select connected / select touching)
- it is very difficult to properly attach new elements (lines, quads, etc) to these vertices, as only one vertex must be selected, forcing to zoom a lot to reach one of the vertices.
This is mildly annoying when building a new part (high precision of LDPE minimizes the mismatches), it is VERY annoying when reworking a part that was previously rounded...

So, as a user, I'd like to be able to define a "fuzzyness factor", distance below which vertices would be considered the same. This would work of course for selection extension, but also to attach new elements (this new element would be attached to one of these vertices at random).

[Nils Schmidt]

While your at it:
A click on the red close-cross in the text-editor, closes only that tab in the text-editor.
A click on the red close-cross in the 3D-editor, closes both tabs, in 3D and text-editor.

What is the desired behaviour?

[Willy Tschager]

While your at it:
A click on the red close-cross in the text-editor, closes only that tab in the text-editor.
A click on the red close-cross in the 3D-editor, closes both tabs, in 3D and text-editor.

What is the desired behaviour?

A click on the red close-cross of either 3D-editor or text closes both tabs.

w.

[Philippe Hurbain]

What is the desired behaviour?

My choice is just above... But maybe it's just me

[Nils Schmidt]

- it is very difficult to properly attach new elements (lines, quads, etc) to these vertices, as only one vertex must be selected, forcing to zoom a lot to reach one of the vertices.
This is mildly annoying when building a new part (high precision of LDPE minimizes the mismatches), it is VERY annoying when reworking a part that was previously rounded...

I already introduced an internal distance below which vertices would be considered the same, but it is not correctly defined/working?!
You wish to customize this distance. I can do this, but I have to find out first what is causing the issue with the implementation which is already there.
I created an issue (#587).

- selection doesn't extend past these slight mismatches (select connected / select touching)

There is already an option to select "...with Specified Accuracy" (for select connected / select touching).

[Philippe Hurbain]

There is already an option to select "...with Specified Accuracy" (for select connected / select touching).

Sorry, missed that...

[Nils Schmidt]

it is very difficult to properly attach new elements (lines, quads, etc) to these vertices, as only one vertex must be selected, forcing to zoom a lot to reach one of the vertices.
So, as a user, I'd like to be able to define a distance below which vertices would be considered the same.

This would also mean that this distance would be in the 2D space of the view and not the real distance between the vertices.

[Magnus Forsberg]

Mine too.
A click on the red close-cross of either 3D-editor or text closes both tabs.

[Nils Schmidt]

Mine too.
A click on the red close-cross of either 3D-editor or text closes both tabs.

I fixed this issue (#589).
It will be included in the next release.

[Magnus Forsberg]

- it is very difficult to properly attach new elements (lines, quads, etc) to these vertices, as only one vertex must be selected, forcing to zoom a lot to reach one of the vertices.

I've even seen some funny cond-lines created on these clouds of vertices.
Snapped to the first vertex, and then trying to snap to the second, I seemed to have created a condline without controlpoints, but after zooming in real close I saw a cond-line with very, very short control points.

[Nils Schmidt]

- it is very difficult to properly attach new elements (lines, quads, etc) to these vertices, as only one vertex must be selected, forcing to zoom a lot to reach one of the vertices.

I've even seen some funny cond-lines created on these clouds of vertices.
Snapped to the first vertex, and then trying to snap to the second, I seemed to have created a condline without controlpoints, but after zooming in real close I saw a cond-line with very, very short control points.

Yes... the old implementation was strange. I checked the real distance between the vertices, not the vertex distance on the screen. I am pretty sure that these issue are gone in the next release :)

[Nils Schmidt]

Bug of the day:

* I'm irritated by the fact that the 3D editor places the tab of a newly opened part on the left of an already opened part, while in the text editor it is placed as expected on the right.

w.

I am not able to reproduce this. How can I reproduce this?


I created an issue (#586).

[Philippe Hurbain]

Why ??? I really meant 3d distance !

[Philippe Hurbain]

Not sure we are speaking of the same issue. I was speaking of vertices very close in 3d space, not 2d distance in screen projection. And I have seen thee condline problem described by Magnus for example between a well defined vertex at one end, and a cluster of very close vertices in 3d. The 2d problem is often not an issue, you just have to slightly adjust viewpoint. 2d is really an issue only when we try to work  in -say- front view. 

[Magnus Forsberg]

I am not able to reproduce this. How can I reproduce this?

Just open any file. The order of the tabs in 3D-view is reversed.

   

[Nils Schmidt]

Not sure we are speaking of the same issue. I was speaking of vertices very close in 3d space, not 2d distance in screen projection. And I have seen thee condline problem described by Magnus for example between a well defined vertex at one end, and a cluster of very close vertices in 3d. The 2d problem is often not an issue, you just have to slightly adjust viewpoint. 2d is really an issue only when we try to work  in -say- front view. 

The problem is that "what is close" depends on the zoom level, too. At 1000% zoom 0.1 LDU is a long distance. At 0.1% zoom the vertices are indistinguishable.

[Nils Schmidt]

I am not able to reproduce this. How can I reproduce this?

Just open any file. The order of the tabs in 3D-view is reversed.

Thanks! I was able to fix this issue (#586).

[Philippe Hurbain]

Sure, but two vertices 0.001 ldu apart are still 0.001 ldu apart wether I zoom close out far!!! That's why I suggest to consider vertices with a low enough distance in 3d space (say 0.001 ldu) to be one unique vertex.

[Nils Schmidt]

Text-editor:

• If I hit the Save-button twice, the button stays in 'down'-position.
  
• Why do the cursor jump to the first line when I hit 'Save'? I work with the 'Insert after cursor' activated and don't like to find stuff added in the header after a Save.
  

I fixed this issue (#581).

[Nils Schmidt]

Sure, but two vertices 0.001 ldu apart are still 0.001 ldu apart wether I zoom close out far!!! That's why I suggest to consider vertices with a low enough distance in 3d space (say 0.001 ldu) to be one unique vertex.

I have very good news :D
Today, I implemented a "fuzziness factor" of 0.001 LDU, which will consider vertices within this range as "one" if you add something (e.g. a line, triangle, quad, etc.), regardless of the current zoom level.
You can customise this factor within the range of zero and one LDU. Setting the factor to zero will disable this feature.

(Issue #591)

[Nils Schmidt]

...as a user I want the hover over right click menu-icon to be placed somewhere else. Or that it closes again when I hover outside that menu. I don't like that it opens when I accidentally pass over it. It stays open untill I click on something, forcing me to click twice, once to close that menu, and a second time to choose want I intended to do.

Today, I fixed issue #580.
The menu will now stay closed when the cursor is outside the 3D canvas. I also increased the trigger delay a little bit.

[Philippe Hurbain]

Excellent news indeed!

[Nils Schmidt]

Milestone 0.8.36 is complete.
I am preparing the release right now.

edit: I have some deployment troubles. I expect the release to be ready on the next weekend.

[Magnus Forsberg]

Could you please have look into this issus?

http://www.ldraw.org/cgi-bin/ptdetail.cg...16p6ua.dat

I've made a few changes to it, but there seem to be some undetected coplanar quads still in it.
They are triggered as bad in LDDP, but not in LDPE.

[Nils Schmidt]

Could you please have look into this issus?

http://www.ldraw.org/cgi-bin/ptdetail.cg...16p6ua.dat

I've made a few changes to it, but there seem to be some undetected coplanar quads still in it.
They are triggered as bad in LDDP, but not in LDPE.

Unfortunately, I am not able to exactly re-implement the coplanarity detection of program XYZ.
Coplanarity detection uses floating point arithmetic!
How many errors are detected? Which lines are affected? I actually see some warnings if I lower the threshold from 1 to 0.5 Degree...

However, I will implement a "Coplanarity Heatmap Mode" where you can visually identify quads which are near the coplanarity limit (issue #593).

Additionally, it will be possible to customise the coplanarity threshold someday (#594).

If you really want to have the same behaviour for different applications, then they have to use a common open source library (e.g. for coplanarity detection) with strict floating point arithmetic or arbitrary precision.

[Philippe Hurbain]

As far as I remember, Lddp uses the same code as my planar check tool whose source code is available here:
http://www.philohome.com/isecalc/planarcheck.htm

[Magnus Forsberg]

How many errors are detected? Which lines are affected?

Here it is:

Code:

Line 175: Quad points not coplaner (angle = 1.2265054068335): 4 4 112.085 38.386 -221.054 111.46 38.485 -221.633 111.545 38.544 -221.711 112.59 39.181 -222.486
Line 332: Quad points not coplaner (angle = 1.50922319872091): 4 4 94.943 16.674 -167.907 96.878 15.839 -163.15 95 15.339 -162.066 93.525 14.954 -161.252
Line 759: Quad points not coplaner (angle = 1.21992645119388): 4 4 68.263 14.641 -173.294 68.781 13.939 -170.416 67.181 14.451 -172.857 67.803 15.229 -175.714
Line 760: Quad points not coplaner (angle = 4.73208033097235): 4 4 68.781 13.939 -170.416 68.263 14.641 -173.294 69.613 14.209 -171.234 71.2145 13.6901 -168.7692
Line 1844: Quad points not coplaner (angle = 1.68282257065316): 4 4 96.185 11.242 -143.558 94.862 11.329 -144.709 95.839 11.561 -145.147 95.928 11.577 -145.167
Line 2578: Quad points not coplaner (angle = 1.01441853019529): 4 4 88.846 47.396 -249.679 92.199 46.517 -247.035 92.317 46.228 -246.438 88.818 47.385 -249.664
Line 3000: Quad points not coplaner (angle = 1.07892281220831): 4 4 41.13 5.384 -141.334 40.56 5.234 -140.711 40.66 5.414 -141.619 41.483 5.488 -141.774
Line 4056: Quad points not coplaner (angle = 1.23219607682612): 4 4 85.284 45.945 -247.838 86.037 45.923 -247.587 85.761 45.742 -247.311 85.252 45.931 -247.821

I have the "Normal Angle Coplanarity Limit" set to 1

[Nils Schmidt]

How many errors are detected? Which lines are affected?

Here it is:

Code:

Line 175: Quad points not coplaner (angle = 1.2265054068335): 4 4 112.085 38.386 -221.054 111.46 38.485 -221.633 111.545 38.544 -221.711 112.59 39.181 -222.486
Line 332: Quad points not coplaner (angle = 1.50922319872091): 4 4 94.943 16.674 -167.907 96.878 15.839 -163.15 95 15.339 -162.066 93.525 14.954 -161.252
Line 759: Quad points not coplaner (angle = 1.21992645119388): 4 4 68.263 14.641 -173.294 68.781 13.939 -170.416 67.181 14.451 -172.857 67.803 15.229 -175.714
Line 760: Quad points not coplaner (angle = 4.73208033097235): 4 4 68.781 13.939 -170.416 68.263 14.641 -173.294 69.613 14.209 -171.234 71.2145 13.6901 -168.7692
Line 1844: Quad points not coplaner (angle = 1.68282257065316): 4 4 96.185 11.242 -143.558 94.862 11.329 -144.709 95.839 11.561 -145.147 95.928 11.577 -145.167
Line 2578: Quad points not coplaner (angle = 1.01441853019529): 4 4 88.846 47.396 -249.679 92.199 46.517 -247.035 92.317 46.228 -246.438 88.818 47.385 -249.664
Line 3000: Quad points not coplaner (angle = 1.07892281220831): 4 4 41.13 5.384 -141.334 40.56 5.234 -140.711 40.66 5.414 -141.619 41.483 5.488 -141.774
Line 4056: Quad points not coplaner (angle = 1.23219607682612): 4 4 85.284 45.945 -247.838 86.037 45.923 -247.587 85.761 45.742 -247.311 85.252 45.931 -247.821

I have the "Normal Angle Coplanarity Limit" set to 1

Thank you Magnus!
LDDP is correct. I was able to reproduce and fix this issue (#596). The fix will be included in the upcoming release!

[Zach Whiteman]

I've messed with java enough to know that it's not the problem. When I run the Batch file, a command line window pops up, spits some text out that I can't read, and then exits. Nothing else happens. Do I need to place the folder in a different location? I'll try editing the batch file to point directly to the *.jar file and see what happens.

[Willy Tschager]

I've messed with java enough to know that it's not the problem. When I run the Batch file, a command line window pops up, spits some text out that I can't read, and then exits. Nothing else happens. Do I need to place the folder in a different location? I'll try editing the batch file to point directly to the *.jar file and see what happens.

I placed mine in the "Documents" folder. The Programs folder didn't work.

w.

[Zach Whiteman]

I've messed with java enough to know that it's not the problem. When I run the Batch file, a command line window pops up, spits some text out that I can't read, and then exits. Nothing else happens. Do I need to place the folder in a different location? I'll try editing the batch file to point directly to the *.jar file and see what happens.

I placed mine in the "Documents" folder. The Programs folder didn't work.

w.

I found the issue, and it's that I'm an idiot. I only had the 32-bit Java JRE installed, rather than both the 32 and 64-bit.

[Willy Tschager]

... it's that I'm an idiot.

Welcome on bord than, we are already in two.

w.

[Magnus Forsberg]

Isn't it strange that the error so often is located between the keyboard and the chair?