LDraw.org Discussion Forums

Full Version: Introducing a second HL library?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6
Are there CSG file formats? I wouldn't consider POV-Ray a "file format" since it can contain so many other things besides CSG.
OpenSCAD, OpenJSCAD, some special languages, and some CAD/solid modeling software.
Steffen Wrote:We should more focus on fixing the remaining [few!] errors in official files

What do you mean by a 'few' files?
This page presents over 700 official files to fix.

I had a look into some of the broken parts that was pointed out in this thread, and I doubt that a quick fix, only flipping bad quads and making them bfc is going to give us good parts that render well. I found gaps, missing lines and surfaces, missplaced lines and surfaces, missing cond-lines, non-primitives. Older designs, made in the early days, that don't live up to todays standards.
(These are now corrected and uploaded to PT (Minifig Robot Leg, Flippers, Minifig Lifevest and more.)

They all seem to need far more work than a program could fix. They also need the hand of a human part author with a good eye. Would a 'simple' tool correct those errors? Can LDCad do that?

I see this as yet another argument for never releasing a new part that 'needs work'. We will forever be caugth in a never ending spiral of correcting designs that should have been 'correct' at the first release.
But we can (and imho that's the way to go) correct the blatant errors that can be easily auto-corrected, and then, if someone feels it, manually fix structural errors... After all, as imperfect as they are, these parts have done the job for years!
True,
let's use the tools we have today, and hope for better tools in the making.
But how do you add normals to a missing surface, or connectivity information to a missing primitive?
Magnus Forsberg Wrote:But how do you add normals to a missing surface,
As Nicola (I think it's him) explained, it's easy to derive normals from a smooth shading algrorithm. Only fine tweaking for special needs would have to rely on human intervention...

Quote:or connectivity information to a missing primitive?
Anyway you can't define connectifity only from primitives (eg. tile in minifig hand). It's a big helper, but not sufficient.
Magnus Forsberg Wrote:Would a 'simple' tool correct those errors? Can LDCad do that?
LDCad currently corrects (from memory have to check for exact listing): non flat quads (2 triangles), hourglass quads, ref captions, duplicate points (quad to triangle, con line to nor line) and all zero matrix col/rows.

These corrections are made (at the ldraw line level) in memory after parsing they are just never written (although code for writing 2..5 lines is present). So with a couple of small adjustments I could make a special version which would rewrite those corrected files when e.g. save all is used.

After which a tool like winmerge could visualize the changes in regards to the original 2014-01 lib in order to do a quick check.

Or I could just limit the saved corrections to hourglass and non flat quads if you think the other ones need intensive human intervention/checkups.
I read about this sad news a month ago, very sudden indeed still not much details available though.

steerco/webadmin: Doesn't this news deserve a frontpage / Announcements forum notice now it more confirmed?
Hey Roland,

at first: sorry for the delay.

Roland Melkert Wrote:I too was thinking .obj, I just don't know if it allows for extension without confusing other software capable of importing 'clean' obj. Because it would be very nice to use standard .obj for the main mesh etc but still have the option to (at least) add conditional lines without breaking the format for other tools to use it as is.
As far as I found out, there is no possibility to extend the normal .obj-format. Indeed, that would have been a great solution.

Roland Melkert Wrote:Generating the basic .obj would actually be pretty basic as it's almost the same info/data you need to generate in order to draw the part efficiently in OpenGL.
Agreed.

I made a little experiment and created a JSON compatibe file that could be a basis for a further discussion. Here you can see the conversion of the file "s\3002s01.dat":

Code:
{
  "Header": {
    "Description": "~Brick  2 x  3 without Front Face",
    "Name": "s\3002s01.dat",
    "Author": "James Jessiman",
    "!LDRAW_ORG": "Subpart UPDATE 2003-03",
    "!LICENSE": "Redistributable under CCAL version 2.0 : see CAreadme.txt"
  },    
  "Metadata": {
    "BFC": "CCW"
  },
  "History": {
    "2002-05-07": "[unknown] BFC Certification"
    "2003-07-03": "[Steffen] Subfiled for patterns"
    "2003-12-19": "[PTadmin] Official Update 2003-03"
    "2007-08-29": "[PTadmin] Header formatted for Contributor Agreement"
    "2008-07-01": "[PTadmin] Official Update 2008-01"
  },
  "Vertices": [
    {
      "Position": [30, 24, 20],
      "Color": 16
    },
    {
      "Position": [26, 24, 16],
      "Color": 16
    },
    {
      "Position": [-26, 24, 16],
      "Color": 16
    },
    {
      "Position": [-30, 24, 20],
      "Color": 16
    },
    {
      "Position": [-26, 24, -16],
      "Color": 16
    },
    {
      "Position": [-30, 24, -20],
      "Color": 16
    },
    {
      "Position": [26, 24, -16],
      "Color": 16
    },
    {
      "Position": [30, 24, -20],
      "Color": 16
    },
    {
      "Position": [30, 0, 20],
      "Color": 24
    },
    {
      "Position": [-30, 0, 20],
      "Color": 24
    },
    {
      "Position": [-30, 0, -20],
      "Color": 24
    },
    {
      "Position": [30, 0, -20],
      "Color": 24
    },
    {
      "Position": [30, 24, 20],
      "Color": 24
    },
    {
      "Position": [-30, 24, 20],
      "Color": 24
    },
    {
      "Position": [-30, 24, -20],
      "Color": 24
    },
    {
      "Position": [30, 24, -20],
      "Color": 24
    },
    {
      "Position": [-30, 0, -20],
      "Color": 16
    },
    {
      "Position": [30, 0, -20],
      "Color": 16
    },
    {
      "Position": [30, 0, 20],
      "Color": 16
    },
    {
      "Position": [-30, 0, 20],
      "Color": 16
    }
  ],
  "Meshes": [
    {
      "Ref": {
        "Position": [10, 4, 0],
        "Orientation": [1, 0, 0, 0, -5, 0, 0, 0, 1],
        "File": "stud4.dat"
      },
      "Ref": {
        "Position": [-10, 4, 0],
        "Orientation": [1, 0, 0, 0, -5, 0, 0, 0, 1],
        "File": "stud4.dat"
      },
      "Ref": {
        "Position": [0, 24, 0],
        "Orientation": [26, 0, 0, 0, -20, 0, 0, 0, 16],
        "File": "box5.dat"
        "BFC": "Invert"
      },
      "Quad": {
        "Vertices": [0, 1, 2, 3]
      },
      "Quad": {
        "Vertices": [3, 2, 4, 5]
      },
      "Quad": {
        "Vertices": [5, 4, 6, 7]
      },
      "Quad": {
        "Vertices": [7, 6, 1, 0]
      },
      "Line": {
        "Vertices": [8, 9]
      },
      "Line": {
        "Vertices": [9, 10]
      },
      "Line": {
        "Vertices": [10, 11]
      },
      "Line": {
        "Vertices": [11, 8]
      },
      "Line": {
        "Vertices": [12, 13]
      },
      "Line": {
        "Vertices": [13, 14]
      },
      "Line": {
        "Vertices": [14, 15]
      },
      "Line": {
        "Vertices": [15, 12]
      },
      "Line": {
        "Vertices": [12, 8]
      },
      "Line": {
        "Vertices": [13, 9]
      },
      "Line": {
        "Vertices": [15, 11]
      },
      "Line": {
        "Vertices": [14, 10]
      },
      "Quad": {
        "Vertices": [16, 17, 18, 19]
      },
      "Quad": {
        "Vertices": [18, 0, 3, 19]
      },
      "Quad": {
        "Vertices": [19, 3, 5, 16]
      },
      "Quad": {
        "Vertices": [17, 7, 0, 18]
      },
      "Ref": {
        "Position": [20, 0, 10],
        "Orientation": [1, 0, 0, 0, 1, 0, 0, 0, 1],
        "File": "stud.dat"
      },
      "Ref": {
        "Position": [0, 0, 10],
        "Orientation": [1, 0, 0, 0, 1, 0, 0, 0, 1],
        "File": "stud.dat"
      },
      "Ref": {
        "Position": [-20, 0, 10],
        "Orientation": [1, 0, 0, 0, 1, 0, 0, 0, 1],
        "File": "stud.dat"
      },
      "Ref": {
        "Position": [20, 0, -10],
        "Orientation": [1, 0, 0, 0, 1, 0, 0, 0, 1],
        "File": "stud.dat"
      },
      "Ref": {
        "Position": [0, 0, -10],
        "Orientation": [1, 0, 0, 0, 1, 0, 0, 0, 1],
        "File": "stud.dat"
      },
      "Ref": {
        "Position": [-20, 0, -10],
        "Orientation": [1, 0, 0, 0, 1, 0, 0, 0, 1],
        "File": "stud.dat"
      }      
    }
  ]
}

I do not know the JSON format very well, so please be lenient when there are errors. This should only inspire the discussion.

With something like this it would be easy to add normals or uv-maps. It would be possible to create gradient brushes and for the rubber parts we could also add bones and bone weights ;-). It would be possible to add render-information (e.g. for the slopes) and we could add hide-conditions or something like that.

But: this would be a new format...

Rolf
I don't think that file is a good example, or maybe it is...

If it was made from todays primitives it would be simplified to something like this:
.
Code:
1 16 0 4 0 1 0 0 0 -5 0 0 0 1 stug4-1x2.dat
0 BFC INVERTNEXT
1 16 0 24 0 26 0 0 0 -20 0 0 0 16 box5.dat
4 16 30 24 20 26 24 16 -26 24 16 -30 24 20
4 16 -30 24 20 -26 24 16 -26 24 -16 -30 24 -20
4 16 -30 24 -20 -26 24 -16 26 24 -16 30 24 -20
4 16 30 24 -20 26 24 -16 26 24 16 30 24 20
1 16 0 24 0 30 0 0 0 -24 0 0 0 20 box4t.dat
1 16 0 0 10 1 0 0 0 1 0 0 0 1 stug-1x3.dat
1 16 0 0 -10 1 0 0 0 1 0 0 0 1 stug-1x3.dat
Pages: 1 2 3 4 5 6