[0.2.1] LDForge

[Santeri Piippo]

It works with decimals but isn't always able to find a solution. As I said it's quite cheap and isn't totally fool-proof. It cannot find any solutions for 10.4 - 23.5 but gets this for 10 - 23.5..

Code:

Ring 20, scale by 0.5 (10 -> 10.5)
Ring 7, scale by 1.5 (10.5 -> 12)
Ring 8, scale by 1.5 (12 -> 13.5)
Ring 3, scale by 4.5 (13.5 -> 18)
Ring 12, scale by 1.5 (18 -> 19.5)
Ring 39, scale by 0.5 (19.5 -> 20)
Ring 20, scale by 1 (20 -> 21)
Ring 14, scale by 1.5 (21 -> 22.5)
Ring 45, scale by 0.5 (22.5 -> 23)
Ring 46, scale by 0.5 (23 -> 23.5)

Still indeed needs work..

[Santeri Piippo]

I've heavily reworked and improved the algorithm now. It should find more solutions and tries harder to find the most optimal one.
http://pastebin.com/kP9RXd9a

Unfortunately it still cannot find rings between 10.4 and 23.5. Rings and Cones seems to find one but I don't think this is anything but a rare corner case anyway... and even then Rings and Cones prints a 5 ring solution.

The algorithm now gets this for 10 - 23.5:

Code:

Ring 10, scale by 1 (10 -> 11)
Ring 1, scale by 11 (11 -> 22)
Ring 44, scale by 0.5 (22 -> 22.5)
Ring 45, scale by 0.5 (22.5 -> 23)
Ring 46, scale by 0.5 (23 -> 23.5)

Rings and Cones gets a 4 ring solution. I don't think I have the patience to improve this any further.
Plus this does have the advantage of being much faster than Rings and Cones at finding the solutions!

I think I'll make a sample program using this algorithm so that people can try it out.

EDIT: Updated. Turned out that r1 / 2 is a particularly good splitting point since the area between r1 / 2 and r1 can be covered with a single ring1. This chomps another ring off the 10 - 23.5 case:

Code:

Ring 10, scale by 1 (10 -> 11)
Ring 22, scale by 0.5 (11 -> 11.5)
Ring 46, scale by 0.25 (11.5 -> 11.75)
Ring 1, scale by 11.75 (11.75 -> 23.5)

This is in fact the other of Rings and Cones' 4-ring answers, albeit the rings are in different order the numbers are the same. Not too bad, mmh?

[Philippe Hurbain]

Santeri,
I used LDForge to sort out lines/condlines when creating these hair parts but when I imported the meshes some triangles (one or two per mesh) were dropped out by LDForge, leaving a hole.

Otherwise, one feature I'd like (and which shouldn't be too difficult to implement) is a hide/unhide condlines button...

[Santeri Piippo]

I used LDForge to sort out lines/condlines when creating these hair parts but when I imported the meshes some triangles (one or two per mesh) were dropped out by LDForge, leaving a hole.

Sorry for the late reply, I've been busy with studies and all, but now I got that stuff out of the way and I'm going to graduate later today.

There turned out to actually be a rather glaring bug in 0.2 which causes every 300th line to be skipped. I've patched this for 0.3 which I hope to put out soon, before Christmas hopefully.

EDIT: actually screw it, I'll hotfix it.

Otherwise, one feature I'd like (and which shouldn't be too difficult to implement) is a hide/unhide condlines button...

I could slip this in.

[Santeri Piippo]

Version 0.2.1 of LDForge is now out, fixing a bug causing LDForge to skip every 300th line of a given file. See release document and downloads here

[Philippe Hurbain]

rather glaring bug in 0.2 which causes every 300th line

A nice one, with hair on legs and all

[Santeri Piippo]

It's funny enough that it was just a matter of removing 3 characters in the code to fix that...

[Michael Heidemann]

I just downloaded and extract the zip.

If I try to open the file 44937s01.dat LDForge immediately crashes.
I tried the same as admin, but the same result.

What is going wrong on my machine (win8)?

[Stan Isachenko]

I just downloaded and extract the zip.
If I try to open the file 44937s01.dat LDForge immediately crashes.
I tried the same as admin, but the same result.
What is going wrong on my machine (win8)?

I had the same problem, but then i found solution. I create new file, put some triangles there and save it. Then other parts start to open normaly.

[Michael Heidemann]

Strange behaviour - but thanks for the hint - it works

[Michael Heidemann]

Now I opened an existing file that has a good BFC winding (52038.dat) but LDForge gives only red surfaces except the studs.
I think here should be done a little bit.

[Santeri Piippo]

Now I opened an existing file that has a good BFC winding (52038.dat) but LDForge gives only red surfaces except the studs.
I think here should be done a little bit.

The BFC support is currently rather primitive, it mostly assumes everything is CCW and doesn't manage INVERTNEXT within subfiles either. I plan on rewriting the BFC support but that's not possible with the current level of GL-fu involved. After 0.3 I'm planning on upgrading to VAO's which should allow for proper BFC support.

As for that weird crash mentioned I'm not sure what to think about it. I can open the subpart just fine, and there's massive beneath-the-hood changes in 0.3 anyway, so I guess all I can do is hope it'll behave better once 0.3 is out.

[Santeri Piippo]

Alright, update. The new version seems to be mainly functional but the overall sloppiness of the GL renderer really hurts things. I'd really love to update to OpenGL 3 now and use vertex array objects, however with my implementation of it the compiler (where the LDraw data is processed to GL data) for some inexplainable reason gets slower each time it is used. I don't understand why this is, but it just is.

So I guess I'll just have to release 0.3 without OpenGL 3 support. I still have to iron out a bug out before I can post a beta.

[Roland Melkert]

You don't need OpenGL 3.0 for VBO it's available from 1.5 and up.

As on the slowdown, are you sure you aren't leaking (gl) resources?

[Santeri Piippo]

You don't need OpenGL 3.0 for VBO it's available from 1.5 and up.

Oh, I see. I'm using VAO though, not VBO.

As on the slowdown, are you sure you aren't leaking (gl) resources?

Pretty sure. Most of the data management is done by QVectors, the compiler just allocates some QVectors and I don't think that's leaking anything..

Further, it seems the inlining process also slows down along with the rest of the operations, although using the exact same inlining yields no slowdown with 500 repeats outside the compilation process. I have no idea why this is.

[Tim Gould]

Could you be running into caching issues? e.g. could, for some reason, the data be stored non-contiguously in the compiled version?

Just a quick thought. It's definitely a cause of slow-down in codes that do large-scale operations.

Tim

[Roland Melkert]

I'm using VAO though, not VBO.

Yes but VAO is basically VBO++

For LDraw purposes (especially if you are just drawing single parts) VBO is good enough IMHO. Also not everyone has OpenGL 3.0 available.

[Santeri Piippo]

I'm using VAO though, not VBO.

Yes but VAO is basically VBO++

So VAO has higher requirements than VBO does? I thought it was the other way around...

Now I seriously have to rethink things. So to get things straight:

- VAO is newer and requires OpenGL 3.0
- VBO is older and requires OpenGL 1.5

I thought VBO needed GL4 o_O

[Travis Cobbs]

VBO has been around since OpenGL 1.5, but I don't think it was an officially required part of 1.5. However, if my reading of the Wikipedia article is correct, it became required functionality in OpenGL 2.1. LDView uses VBO, and as far as I can tell by my source control, has been doing so for close to 10 years.

On Windows, LDView uses wglGetProcAddress() to get function pointers for all GL extensions, and it treats VBO as an extension. (On other platforms, its function pointers point to the functions declared in the GL headers.) LDView also uses glGetString(GL_EXTENSIONS) to get the list of extensions, and only uses VBO if GL_ARB_vertex_buffer_object is in the list of extensions. Note that if VBO became main-line in OpenGL 2.1, you could also check that the GL version is at least 2.1, but checking for GL_ARB_vertex_buffer_object is more inclusive. Warning: if you call glGetString(GL_EXTENSIONS), don't make any assumptions about the length of the returned string by copying it into a fixed-sized buffer. The extensions string is extremely long. Also, don't use a substring search to see if an extension is present. Parse the string, separating it out into separate tokens separated by space.

LDView does have fallback code if VBO is not available, so I don't have any real way of knowing how widespread its support is. However, I'm pretty sure that even really old cards (made before 2004) support VBO if they have the latest available drivers installed. Both nVidia and ATI add functionaity to older cards in driver updates when the cards can support that functionality.

[Santeri Piippo]

Alright then, my knowledge must've been really wrong then. I will look into VBOs and get around to implementing them into LDForge.

Warning: if you call glGetString(GL_EXTENSIONS), don't make any assumptions about the length of the returned string by copying it into a fixed-sized buffer. The extensions string is extremely long. Also, don't use a substring search to see if an extension is present. Parse the string, separating it out into separate tokens separated by space.

Hm. What's the proper way to get the string data then? How do I go around to know the length?

[Roland Melkert]

I would suggest using something like GLEW

http://glew.sourceforge.net/

It will take care of all the binding for you, you then only have to check for define's/consts to know if something is safe to use.

[Travis Cobbs]

It returns a NULL-terminated string, and you can use strlen to determine the length of that string (after a typecast to const char *). Just don't copy it into a pre-allocated buffer. You can also use a 3rd-party extension handling library like Roland suggests.

Also, a simple substring search isn't good, because nothing prevents an extension name from being an exact subset of another extension name. I already had a piece of code that takes a string and a separator as input, and returns a dynamically allocated array of strings as ouput, so I just use that with the extensions string and space.

[Santeri Piippo]

Hrm. So I started putting this together and while (after a few hours of headache) got it to actually draw things on the screen, what it draws is way off.

It seems to always use the same strange 4 vertices.


This is the initial view, with the "axes" drawn on the screen..


and this shows up after I add a quad, no matter what shape it is.

Why would it use the same vertices all the time? These are my relevant source files:
https://github.com/arezey/ldforge/blob/g...ompiler.cc
https://github.com/arezey/ldforge/blob/g...enderer.cc

[Roland Melkert]

After a quick glance the gl stuff seems ok, but...

I see you work with arrays called *indices*

Yet in the gl part you only bind vertex data and draw stuff with drawArrays. If you want to render indexed vertices you have to use two kinds of VBO's (GL_ELEMENT_ARRAY_BUFFER and GL_ARRAY_BUFFER) and use drawElements instead.

So you might just be drawing the first couple of unique vertices of the object.

[Santeri Piippo]

I just have arrays of coordinates as floats. I don't index my vertices like that (though perhaps I should look into that sometime). Perhaps I should name the members more clearly..

[Roland Melkert]

Are you sure the correct data is send to vbo? You seem to do a lot of data copying, why not store the obj data in glFloat vectors to start with so you can send it 1 on 1 to vbo.

Are all the gl calls returning OK (glGetError)?

I'm not completely sure bit it might be needed to enable the vbo clientstate for the initial data copy (it is in my code, but I'm not sure it's needed)

Also I noticed you bind the buffer twice, once before and once after a command. That's not needed it's better to bind to id '0' when done with vbo (e.g after drawarrays)

[Santeri Piippo]

Are you sure the correct data is send to vbo?

Yes, I've ensured this with debug printing.

You seem to do a lot of data copying, why not store the obj data in glFloat vectors to start with so you can send it 1 on 1 to vbo.

I want to avoid overhead that would result from compiling the entire part model each time something changes, instead having a vector for each object and then merging to create the resulting vector for the vbo.

Perhaps some pointer-and-size stuff could be used to eliminate the data copying but right now my first priority is to get a brick on the screen.

Are all the gl calls returning OK (glGetError)?

hrm... I'm gonna have to check this.

I'm not completely sure bit it might be needed to enable the vbo clientstate for the initial data copy (it is in my code, but I'm not sure it's needed)

Enabling the clientstate for the buffering doesn't change anything.

Also I noticed you bind the buffer twice, once before and once after a command. That's not needed it's better to bind to id '0' when done with vbo (e.g after drawarrays)

Ah, the Wikipedia article Travis linked implied it was necessary.

[Santeri Piippo]

Hmm. Interesting, the glBufferData() call yields GL_INVALID_OPERATION. The reference says this is generated "if the reserved buffer object name 0 is bound to target."

Further inspection reveals that the glGenBuffers() calls leave the VBOs 0 with no error generated. What gives..?

EDIT: http://www.opengl.org/discussion_boards/...ost1253052
hhrrmm...

[Roland Melkert]

I was wondering what the value of VBO_NumArrays was (it's not defined in the two sources you gave)

Also you are supplying the wrong count to drawArrays in at least one place (6 instead of 18) but I doubt that is causing the main problem.

[Roland Melkert]

Are you sure the OpenGL context is current at the time of genBuffers?

[Santeri Piippo]

I was wondering what the value of VBO_NumArrays was (it's not defined in the two sources you gave)

Also you are supplying the wrong count to drawArrays in at least one place (6 instead of 18) but I doubt that is causing the main problem.

Actually the post in the link I posted turned out to be right. glGenBuffers may only be called inside initializeGL.

Now the VBOs get rendered correctly.. but everything else (the Qt-stuff) isn't..

[Roland Melkert]

That's probably because you don't do a bind to 0 afterwards

Also if qt is sharing the gl stuff you might need to reset the clientstate stuff

[Santeri Piippo]

That's probably because you don't do a bind to 0 afterwards

This indeed turned out to be the case. Everything's fine now, thanks a lot for the help!

[Roland Melkert]

No thanks,

Bit weird that genBuffers is only allowed in a certain place, I use it all over the place in my LDCad code (i init/copy the vbo data on demand just before the first render of an object). Must be a qt thing.

[Santeri Piippo]

I was wondering what the value of VBO_NumArrays was (it's not defined in the two sources you gave)

Right now it's 8. It's defined in one of the headers included by these files:
https://github.com/arezey/ldforge/blob/g...GLShared.h

[Santeri Piippo]

Hm, maybe. Oh well, at least it works now.

though now it seems the compiler slows down again, perhaps after I refactor things and avoid needless data copying this will get fixed.

lesson of the day: actually pay attention to GL errors...

[Santeri Piippo]

---

[Santeri Piippo]

Status update in again. VBO renderer almost works properly, I've managed to get bricks to draw almost entirely correctly now, in color as well. It seems the slow-down thing stems from the mass amount of inlining the compiler did and that's been cut down now (it inlines any given subfile once and then stores it as polygons in memory now). This makes subfile handling A LOT faster. It doesn't take entire seconds to select or move a cylinder around anymore.

Still not done yet though, but I'm getting there. Once it's all done I'm considering looking into quaternions and breaking the gimbal lock. Perhaps finally get proper BFC red/green view after that.

I'm getting the feeling I should give the version a lot of testing after everything's done and put it out as version 1.0. It's going to still take a while but it'll be a massive update.

[Santeri Piippo]

As much as I'd love to say I'd have progressed over the past weeks the development kind of got stagnated. The vbo renderer kind of relevealed the entire fundamentals are kind of broken. LDForge simply wasn't designed for multi-document editing first up...

So as a result I'm rebuilding this from the ground up. I'll obviously reuse important very modules like part downloading and the renderer but the core needs a rewrite, no way around it.

[Willy Tschager]

How do I change a vertex say from:

3 16 18 4 9 17.491 4.196 9.126 18 1 8

to

3 16 18 4 9 18 5 10 18 1 8

and the change applies also to all other triangles and cond. lines touched by the 17.491 4.196 9.126 vertex (kind of SyncEdit in LDDP).

w.

[Santeri Piippo]

You can use "replace coordinates" (Ctrl+R) to replace a coordinate value on a specific axis within the selection. Select whatever polygons you want to apply the change to and you can replace x=17.491 with x=18 in them.

[Willy Tschager]

Fine. Any chance to add a feature where the entire vertex gets replaced:

17.491 4.196 9.126 with 18 5 10

w.

Ps. Note that there is a strange behaviour when using a , (komma) instead of . (dot) for the decimal.

[Santeri Piippo]

Fine. Any chance to add a feature where the entire vertex gets replaced:

17.491 4.196 9.126 with 18 5 10

Should be doable.

Ps. Note that there is a strange behaviour when using a , (komma) instead of . (dot) for the decimal.

[/quote]
It's Qt-inherited behavior, I don't really know how to get around it.

[Santeri Piippo]

Development is finally back on track. It took me 3 months to find the root cause of some pesky OpenGL artifacts in the vbo renderer but it is at long last behaving like it should.

Now to wrap stuff up. I'll need to reimplement vertex snapping and then see if I can implement the BFC red/green view, basic lighting, breaking gimbal lock and stuff like that.

[Santeri Piippo]

Just got done writing a magic wand tool:

pre-selection:


post-selection:


It selected all of the dark gray polygons.. except for some behind those yellow ones. At first I thought I had a bug.. but turns out the magic wand is pretty effective at catching t-junctions!



In other news I got a bit tired of git and discovered my love for hg, so the repository is now at bitbucket again: https://bitbucket.org/crimsondusk/ldforge

[Santeri Piippo]

I'm getting rather close to a release now. I've managed to make LDForge compilable on Windows again and need to start wrapping up on stability and get the icon set done.

I'm thinking about making an installer with nsis to make things nice and simple. I wonder could I bundle some of Philo's tools with the installer and then have LDForge detect the presence of these tools to automatically set them up instead of needing manual configuration.

[Philippe Hurbain]

I wonder could I bundle some of Philo's tools with the installer

No problem on my side! Just think about potential updates (though I always try to keep compatibility)

[Santeri Piippo]

Sure has been quiet on this front for a while. I've recently made the circle tool able to handle partial as well as high-resolution circles, rings and discs. Also the ring finder algorithm is a bit more reliable and produces more efficient results. Also new is that ldforge now tries to download any un-found files off the parts tracker and can properly be associated with .dat files.

I'm thinking of putting up an unstable beta build. The main thing keeping me from releasing is a highly annoying bug which causes ldforge to randomly crash when a document is closed. For some reason it only happens on Windows. I have no idea how to go about debugging this.

I've also been thinking about the possibility of parsing/processing the header instead of just considering it a bunch of comments at the top of the body. It will certainly be a more involved change and won't happen till the new version is finally out (which may take a while due to the aforementioned problem).

My university studies are beginning so my time pool has kind of diminished a tad. I will still keep on working on ldforge/ldraw parts when I get the chance to. And yes I keep changing my system style all the time.