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


[LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#1
Hey,

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

[Image: imgDuke2.png]
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.
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#2
Eager to test it... Unfortunately not before several days!
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#3
(2017-08-05, 20:20)Philippe Hurbain Wrote: Eager to test it... Unfortunately not before several days!

No problem!
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#4
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..
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#5
(2017-08-06, 14:45)Magnus Forsberg Wrote: ... 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.

Quote:...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.
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#6
(2017-08-07, 23:38)Magnus Forsberg Wrote:
Quote:...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).

(2017-08-07, 23:38)Magnus Forsberg Wrote: As a user I want the hover over right click menu-icon to be placed somewhere else.

I created an issue (#580).

(2017-08-07, 23:38)Magnus Forsberg Wrote: 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.
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#7
(2017-08-08, 5:04)Nils Schmidt Wrote: 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.
Reply
Automagic rounding?
#8
(2017-08-08, 8:54)Magnus Forsberg Wrote: 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?
Reply
RE: Automagic rounding?
#12
(2017-08-08, 19:32)Nils Schmidt Wrote: 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.
Reply
RE: Automagic rounding?
#13
(2017-08-10, 8:42)Magnus Forsberg Wrote: 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.

(2017-08-10, 8:42)Magnus Forsberg Wrote: 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.
Reply
Rectifier: rect-prim creation with adjacent condlines
#9
(2017-08-08, 8:54)Magnus Forsberg Wrote: 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.
Reply
Lines and "Select Connected"
#10
(2017-08-08, 8:54)Magnus Forsberg Wrote: 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).
Reply
Text Editor: Cursor position on save (solved)
#35
(2017-08-08, 8:54)Magnus Forsberg Wrote: 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).
Reply
Hover-Over-Menu (solved)
#37
(2017-08-07, 23:38)Magnus Forsberg Wrote: ...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.
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#11
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.
LEGO ergo sum
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#14
(2017-08-09, 9:46)Willy Tschager Wrote: 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.
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#15
(2017-08-11, 14:11)Magnus Forsberg Wrote: 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
LEGO ergo sum
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#16
+1 too. For me, the desired behavior would be to close file in both text and 3d.
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#18
(2017-08-11, 14:11)Magnus Forsberg Wrote: 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?
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#19
(2017-08-11, 19:30)Nils Schmidt Wrote:
(2017-08-11, 14:11)Magnus Forsberg Wrote: 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.
LEGO ergo sum
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#20
(2017-08-11, 19:30)Nils Schmidt Wrote: What is the desired behaviour?

My choice is just above... But maybe it's just me Wink
Reply
RE: [LDPartEditor] 0.8.35 Beta Released (Selection Filter / Usability)
#24
Mine too.
A click on the red close-cross of either 3D-editor or text closes both tabs.
Reply
Closing a tab -> closes file (solved)
#25
(2017-08-12, 9:44)Magnus Forsberg Wrote: 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.
Reply
Placing of tabs?
#28
(2017-08-09, 9:46)Willy Tschager Wrote: 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).
Reply
RE: Placing of tabs?
#31
(2017-08-12, 10:23)Nils Schmidt Wrote: 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.

   
Reply
RE: Placing of tabs? (solved)
#33
(2017-08-12, 12:41)Magnus Forsberg Wrote:
(2017-08-12, 10:23)Nils Schmidt Wrote: 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).
Reply
RE: [LDPartEditor] "fuzzy" vertices
#17
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).
Reply
RE: [LDPartEditor] "fuzzy" vertices
#21
(2017-08-11, 16:31)Philippe Hurbain Wrote: - 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).

(2017-08-11, 16:31)Philippe Hurbain Wrote: - 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).
Reply
RE: [LDPartEditor] "fuzzy" vertices
#22
(2017-08-11, 19:56)Nils Schmidt Wrote: There is already an option to select "...with Specified Accuracy" (for select connected / select touching).
Sorry, missed that...
Reply
RE: [LDPartEditor] "fuzzy" vertices (selection)
#23
(2017-08-11, 20:26)Philippe Hurbain Wrote: 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.
Reply
RE: [LDPartEditor] "fuzzy" vertices (selection)
#29
Why ??? I really meant 3d distance !
Reply
RE: [LDPartEditor] "fuzzy" vertices
#26
(2017-08-11, 16:31)Philippe Hurbain Wrote: - 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.
Reply
RE: [LDPartEditor] "fuzzy" vertices
#27
(2017-08-12, 9:53)Magnus Forsberg Wrote:
(2017-08-11, 16:31)Philippe Hurbain Wrote: - 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 :)
Reply
RE: [LDPartEditor] "fuzzy" vertices
#30
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. 
Reply
RE: [LDPartEditor] "fuzzy" vertices / zoom
#32
(2017-08-12, 11:47)Philippe Hurbain Wrote: 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.
Reply
RE: [LDPartEditor] "fuzzy" vertices / zoom
#34
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.
Reply
RE: [LDPartEditor] "fuzzy" vertices (solved)
#36
(2017-08-12, 18:34)Philippe Hurbain Wrote: 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)
Reply
RE: [LDPartEditor] "fuzzy" vertices (solved)
#38
Excellent news indeed!
Reply
Milestone 0.8.36 is ready / Deployment issues
#39
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.
Reply
RE: Milestone 0.8.36 is ready / Deployment issues
#40
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.
Reply
Coplanar Quads?
#41
(2017-08-15, 16:37)Magnus Forsberg Wrote: 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.
Reply
RE: Coplanar Quads?
#42
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
Reply
RE: Coplanar Quads?
#43
(2017-08-15, 18:12)Nils Schmidt Wrote: 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
Reply
RE: Coplanar Quads? (Solved)
#44
(2017-08-16, 15:51)Magnus Forsberg Wrote:
(2017-08-15, 18:12)Nils Schmidt Wrote: 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!
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 2 Guest(s)
Forum Jump:


Users browsing this thread: 2 Guest(s)