New Model refinement options in 0.13.xxxx

[shoogen]

I still did get when a reparametrerisation of a bspline curve/surfaces happens.

[jriegel]

Join B-Spline surfaces makes IMO no sense at all. If you remove a Edge inbetween two B-Spline Faces
you could surly do a bigger Face, but in most cases you will get very rough boundary conditions.

In most designs B-Spline surfaces are well tailored special Faces, like e.g. a wind shield or so.

[pperisin]

Hi,

small report on shape refinement - I have attached one example some other user uploaded on forum - I have noticed that refine shape does not fully work on it (at least IMO)

I have attached a file, and in it all faces that I think should be merged are colored in red - if you take a look at original shapes you will see that some faces are merged and some not.

This file is originally from this thread:
viewtopic.php?f=3&t=2993

so you can look at it, just note not to look at finished shape - instead look at the originals of the shape - you will see that they are made with boxes.

Regards
Petar

[tanderson69]

you will see that they are made with boxes.

boxes imported from another system? look at these numbers from the "Galaxy... solid".

Code: Select all

-------
Dump of 6 surfaces 
 -------

   1 : Plane
  Origin :0, 0, 0 
  Axis   :1, 0, 0 
  XAxis  :0, 0, 1 
  YAxis  :0, -1, 0 

   2 : Plane
  Origin :0, 0, 0 
  Axis   :0, 1, 0 
  XAxis  :0, -0, 1 
  YAxis  :1, 0, -0 

   3 : Plane
  Origin :0, 0, 125.300003051758 
  Axis   :0, 0, 1 
  XAxis  :1, 0, -0 
  YAxis  :-0, 1, 0 

   4 : Plane
  Origin :0, 8.71000003814697, 0 
  Axis   :0, 1, 0 
  XAxis  :0, -0, 1 
  YAxis  :1, 0, -0 

   5 : Plane
  Origin :0, 0, 0 
  Axis   :0, 0, 1 
  XAxis  :1, 0, -0 
  YAxis  :-0, 1, 0 

   6 : Plane
  Origin :66.0999984741211, 0, 0 
  Axis   :1, 0, 0 
  XAxis  :0, 0, 1 
  YAxis  :0, -1, 0

I didn't check the other solid, but I am guessing it doesn't match these small differences from nominal. There is NO "slop" in the refinement algorithm.

[tanderson69]

Join B-Spline surfaces makes IMO no sense at all. If you remove a Edge inbetween two B-Spline Faces
you could surly do a bigger Face, but in most cases you will get very rough boundary conditions.

In most designs B-Spline surfaces are well tailored special Faces, like e.g. a wind shield or so.

I agree, however different work flows might produce situations where it does make sense. I have attached a file in attempt to show an example of this.

start solid: simple cube cut with a spline surface and a cube fused. This is simple but represents a complex tool solid that I have linked into numerous solids throughout an assembly to apply 3d shape. Half way through the job I get an engineering change that changes one little area represented by the small, fused cube. I will want modify this tool solid in local, limited way as to help maintain links throughout my assembly.

stepOne solid: this is the tool solid after subtracting a cylinder. This operation cuts out the area made obsolete by the engineering change.

stepTwo solid: this is a solid that will be used to fill the void in the tool solid left by step one. this was made by taking an exact copy of the cylinder used in step one and trimming it with the spline surface and then uniting in the new(engineering change) geometry.

stepThree solid: is simply uniting the new solid from step two with the original modified solid. This solid has two "equal" spline surfaces that should be joined.

[pperisin]

you will see that they are made with boxes.

boxes imported from another system?

Nope, that is the point - boxes were made in FreeCAD, using makebox. I'm guessing they were made in GUI, since user that reported this was asking basic questions, but I might be wrong.

Originals are made in a file attached in a linked thread.

I have tried to reproduce the example with original boxes - in the names you see the order in which shapes were created.

Take a look at the pink faces in:

9-Refined-ThirdCut
and
11-FinalCut

in 9 there is one face, but in 11 there are three pink faces - this was because face of 10-FinalBox was on a single pink face of 11. They do get merged later, but IMO remaining two red faces in 12-Refined-FinalCut-bad should also go with the same face.

I might be wrong here, but please just take a look how this final shape was made - It might be true that I am wrong, but it might not be....

Regards,
Petar

[tanderson69]

what I am finding here is that when parameters are entered with the decimal portion, it tweaks the OCC data some way.

procedure:
1) start freecad. new document etc..
2) add a box feature.
3) set the height, length and width to 20.
4) export brep.
5) start OCC DRAWEXE and restore exported brep.
6) dump restored solid.

something like this: (subset of dump command)

Code: Select all

Dump of 12 Curves 
 -------

   1 : Line
  Origin :0, 0, 0 
  Axis   :0, 0, 1 

   2 : Line
  Origin :0, 0, 20 
  Axis   :-0, 1, 0 

   3 : Line
  Origin :0, 20, 0 
  Axis   :0, 0, 1 

   4 : Line
  Origin :0, 0, 0 
  Axis   :-0, 1, 0 

   5 : Line
  Origin :20, 0, 0 
  Axis   :0, 0, 1 

   6 : Line
  Origin :20, 0, 20 
  Axis   :0, 1, 0 

   7 : Line
  Origin :20, 20, 0 
  Axis   :0, 0, 1 

   8 : Line
  Origin :20, 0, 0 
  Axis   :-0, 1, 0 

   9 : Line
  Origin :0, 0, 0 
  Axis   :1, 0, -0 

  10 : Line
  Origin :0, 0, 20 
  Axis   :1, 0, -0 

  11 : Line
  Origin :0, 20, 0 
  Axis   :1, 0, -0 

  12 : Line
  Origin :0, 20, 20 
  Axis   :1, 0, -0 

 -------

7) back in freecad, change length width and height of box to 20.1
8) export brep
9) OCC DRAWEXE, restore exported brep
10) dump restored solid.

somthing like this: (subset of dump command)

Code: Select all

Dump of 12 Curves 
 -------

   1 : Line
  Origin :0, 0, 0 
  Axis   :0, 0, 1 

   2 : Line
  Origin :0, 0, 20.1000003814697 
  Axis   :-0, 1, 0 

   3 : Line
  Origin :0, 20.1000003814697, 0 
  Axis   :0, 0, 1 

   4 : Line
  Origin :0, 0, 0 
  Axis   :-0, 1, 0 

   5 : Line
  Origin :20.1000003814697, 0, 0 
  Axis   :0, 0, 1 

   6 : Line
  Origin :20.1000003814697, 0, 20.1000003814697 
  Axis   :0, 1, 0 

   7 : Line
  Origin :20.1000003814697, 20.1000003814697, 0 
  Axis   :0, 0, 1 

   8 : Line
  Origin :20.1000003814697, 0, 0 
  Axis   :-0, 1, 0 

   9 : Line
  Origin :0, 0, 0 
  Axis   :1, 0, -0 

  10 : Line
  Origin :0, 0, 20.1000003814697 
  Axis   :1, 0, -0 

  11 : Line
  Origin :0, 20.1000003814697, 0 
  Axis   :1, 0, -0 

  12 : Line
  Origin :0, 20.1000003814697, 20.1000003814697 
  Axis   :1, 0, -0 

 -------

I have done this several times, by using both the gui and python console, and it has been consistent. As soon as you include the fractional part of the new parameter the numbers get tweaked. Like we have some garbage left over from float to double conversion. This is why the model refine is failing to merge faces.

[tanderson69]

As a test I modified "App::DocumentObjectExecReturn *Box::execute(void)" to what follows(just added the qdebug)

Code: Select all

App::DocumentObjectExecReturn *Box::execute(void)
{
    double L = Length.getValue();
    double W = Width.getValue();
    double H = Height.getValue();

    qDebug() << QString::number(L, 'f', 15) << "   " <<
                QString::number(W, 'f', 15) << "   " <<
                QString::number(H, 'f', 15);

    if (L < Precision::Confusion())
        return new App::DocumentObjectExecReturn("Length of box too small");

    if (W < Precision::Confusion())
        return new App::DocumentObjectExecReturn("Width of box too small");

    if (H < Precision::Confusion())
        return new App::DocumentObjectExecReturn("Height of box too small");

    try {
        // Build a box using the dimension attributes
        BRepPrimAPI_MakeBox mkBox(L, W, H);
        TopoDS_Shape ResultShape = mkBox.Shape();
        this->Shape.setValue(ResultShape);
    }
    catch (Standard_Failure) {
        Handle_Standard_Failure e = Standard_Failure::Caught();
        return new App::DocumentObjectExecReturn(e->GetMessageString());
    }

    return App::DocumentObject::StdReturn;
}

Ran freecad and built a box, changed parameters to 20.1, then to 20. The output was as follows.

Code: Select all

"10.000000000000000"     "10.000000000000000"     "10.000000000000000" 
"10.000000000000000"     "10.000000000000000"     "2.000000000000000" 
"10.000000000000000"     "10.000000000000000"     "20.000000000000000" 
"10.000000000000000"     "10.000000000000000"     "20.100000381469727" 
"10.000000000000000"     "10.000000000000000"     "20.100000381469727" 
"10.000000000000000"     "10.000000000000000"     "20.100000381469727" 
"10.000000000000000"     "10.000000000000000"     "20.100000381469727" 
"10.000000000000000"     "10.000000000000000"     "20.100000381469727" 
"2.000000000000000"     "10.000000000000000"     "20.100000381469727" 
"20.000000000000000"     "10.000000000000000"     "20.100000381469727" 
"20.100000381469727"     "10.000000000000000"     "20.100000381469727" 
"20.100000381469727"     "10.000000000000000"     "20.100000381469727" 
"20.100000381469727"     "10.000000000000000"     "20.100000381469727" 
"20.100000381469727"     "10.000000000000000"     "20.100000381469727" 
"20.100000381469727"     "10.000000000000000"     "20.100000381469727" 
"20.100000381469727"     "2.000000000000000"     "20.100000381469727" 
"20.100000381469727"     "20.000000000000000"     "20.100000381469727" 
"20.100000381469727"     "20.100000381469727"     "20.100000381469727" 
"20.100000381469727"     "20.100000381469727"     "20.100000381469727" 
"20.100000381469727"     "20.100000381469727"     "20.100000381469727" 
"20.100000381469727"     "20.100000381469727"     "20.100000381469727" 
"20.100000381469727"     "20.100000381469727"     "20.100000381469727" 
"20.100000381469727"     "20.100000381469727"     "20.100000381469727" 
"20.100000381469727"     "20.100000381469727"     "20.100000381469727" 
"20.100000381469727"     "20.100000381469727"     "2.000000000000000" 
"20.100000381469727"     "20.100000381469727"     "20.000000000000000" 
"20.100000381469727"     "20.100000381469727"     "20.000000000000000" 
"2.000000000000000"     "20.100000381469727"     "20.000000000000000" 
"20.000000000000000"     "20.100000381469727"     "20.000000000000000" 
"20.000000000000000"     "20.100000381469727"     "20.000000000000000" 
"20.000000000000000"     "2.000000000000000"     "20.000000000000000" 
"20.000000000000000"     "20.000000000000000"     "20.000000000000000" 
"20.000000000000000"     "20.000000000000000"     "20.000000000000000"

tried some hacks with memset, did some googling and this is the result of the float to double conversion. We could do some int multiplication and division to round user input, but I am thinking the correct solution is to have the parameters stored as doubles instead of floats. Comments?

[shoogen]

Code: Select all

>>> print (20.100000381469727).hex()
0x1.41999a0000000p+4

We could do some int multiplication and division to round user input, but I am thinking the correct solution is to have the parameters stored as doubles instead of floats. Comments?

using doubles in all Properties is probably the best solution.
I think it is a good idea to support float to double conversion with a special 'round to next base10 representation' function. Unsings integers would set the precision to a fixed numer of decimal places. A better solution would determine the preceion by the value of the exponent.

Code: Select all

>>> f1=20.100000381469727
>>> f2=round(f1,math.floor(-math.log10(f1)+7.22)) if abs(f1) > 2**-26 else 0.0
>>> print f2, f2==20.1, f2.hex()
20.1 True 0x1.419999999999ap+4

[tanderson69]

Code: Select all

>>> print (20.100000381469727).hex()
0x1.41999a0000000p+4

Ah! Thanks for the input. I am not familiar with the memory layout of floating point numbers. I see you are monitoring the bug report, but for everybody else it is here https://sourceforge.net/apps/mantisbt/f ... php?id=840