[0.2.1] LDForge


[0.2.1] LDForge
#1
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



LDForge is released under GPLv3 and CC-BY-SA (for icons). Repository: here, for bleeding-edge stuff.

Some things to note:
  • BFC red/green view, albeit present, isn't always right; it assumes everything is CCW and it fails to catch INVERTNEXT in subfiles. Also it has to draw everything twice so there's a bit of a performance hit.
  • The camera suffers of gimbal lock. I'm going to try address this for future versions.



So in some 2010 I had posted some ideas about this thing. Even though I've been quite wholly inactive, I've had this on the back burner for the past year. I've been learning a lot of programming things and I guess I'm a more mature person today.

Basically I've rewritten the entire thing, instead of Tcl, this thing is being written in C++/Qt/OpenGL. The only stuff I've kept were some OpenGL things I ported from the old renderer to make this actually capable of drawing things. While MLCAD had 4 camera windows, this thing has one single one with 7 modes which can be quickly changed to and from.

Features:
  • List view ala MLCAD with multi-selection. One object per line, one line per object. Items not colored main or edge color (16/24) have their color reflected in the list view for identifying.
  • Parse error recovery, if a line/object cannot be parsed properly it will be displayed as an errorneous object. This object can be selected and its contents edited and have it reparsed, so you can fix these errors within LDForge.
  • 6 camera modes plus a free-angle one.
  • Drawing mode that allows you to literally draw polygons and lines into the screen.
  • Object hiding
  • Select by color or type
  • Quick edge-lining, takes any number of polygons and creates edgelines around them
  • Ability to edit object's LDraw code directly
  • Inlining, plus deep inlining which grinds down to polygons only
  • Auto-coloring (sets color to the first found unused color), uncoloring (sets colors to main/edge color based on type)
  • Coordinate rounding, inverting, coordinate replacing, flipping, quad splitting
  • Screenshotting
  • Vertex object, generic radial primitive object
  • LDConfig.ldr parsing for color information
  • Ability to launch Philo's utilities and automatically merge in output
  • BFC red/green view (incomplete)
  • Wireframe mode, axis drawing
  • Image overlays for getting part data from pictures
Reply
Re: LDForge
#2
Looks nice

Quote: I'm still a Linux user and to be painfully honest I haven't yet managed to compile Qt stuff on Windows yet.. I'll have to figure that out sometime down the line.

I highly recommend using MinGW, especially if you used to Linux. It's basically the essence of bash and gcc on windows. I use it with LDCad (wxWidgets instead of qt though)

I'm mainly on Windows but the only thing I have to do to compile a Linux version is boot up Ubuntu 10 or something open a terminal do svn update and type make Smile This is possible because the MinGW environment is so simular.

Alternative is visual studio but you might need to account for many (minor) compiler differences using tons of #ifdef's etc.
Reply
Re: LDForge
#21
---
Reply
Re: LDForge
#22
----
Reply
Re: LDForge
#24
That's a progress bar !!!
Reply
Re: LDForge
#3
I am really appreciate what you are planning. I hope that will end up with a good tool for part authors. As far as I know currently there is only MLCad for doing visual part authoring on Windows.
I also have a tool like your on my to code list, but so far I have no experience in 3d (openGL or anything else) and therefore I would be happy to see this project done by someone else. Smile You can count on me if you need guys for testing Smile
Reply
Re: LDForge
#4
Thanks guys Smile

Also, yay, it's a brick!
[Image: ldforge-4.png]
Reply
Re: LDForge
#5
I'm excited too. The brick looks very good Smile

Tim
Reply
Re: LDForge
#6
Looks good indeed, count on me for beta tests Wink
Reply
Re: LDForge
#7
I'm glad to see there's interest for this. Smile

Also I just managed to structure inlining in a way that all immediate subfiles (i.e. subfiles the current open file references) are cached into memory for faster processing. I also honed out matrix multiplication and now this thing can properly render more complex parts too:

[Image: ldforge-5.png]
[Image: ldforge-6.png]

Yay for weekend coding.
Reply
Re: LDForge
#8
Keep on Smile
Reply
Re: LDForge
#9
LDConfig.ldr is now parsed and read properly so all colors are available. Working on BFC support now.
Reply
Re: LDForge
#10
When do you think we can test on our systems Smile
Reply
Re: LDForge
#11
When it's ready enough I guess. There's still a lot todo before it's actually usable for its intended purpose rather than looking at parts. Smile
Reply
Re: LDForge
#12
Wher I can download LDForge?
Reply
Re: LDForge
#13
It is still in early development, no releases just yet.
Reply
Re: LDForge
#14
Update: undo/redo stuff done, object moving and 3d selection done, also I've added the quick color toolbar (configurable!). Also I've added this kind of generalized radial primitives (I call them just radials for short) - basically arbitrary circular primitives. The point is that if you need a 1/4 ring 14 in your part, you can just add it and model the part with that without having to deal with primitives that don't exist yet and stuff. They can then be easily resolved into subfile references when you're done with the part. Right now it can do circles, cylinders, discs, disc negatives, rings and cones.

There's still a good lot of things to do before it's actually usable for part editing but I've gotten a lot done recently.
Reply
Re: LDForge
#15
Thanks for the update!!!
Reply
Re: LDForge
#16
Man this has been blazing recently. I've done a lot during the past month. I've gotten a lot of editing stuff done as well as general usability and rendering stuff... including ability to switch between and use the 6 fixed cameras.

And just now I finally managed to get object drawing working:

[Image: planedraw-1.png]
[Image: planedraw-2.png]

This is a major accomplishment for me, even though it only works on the top-down camera for now! Tongue
At this point I guess I should start cleaning stuff out and fixing a few things for an alpha build.
Reply
Re: LDForge
#17
I like to have one of your alpha builds Wink
Reply
Re: LDForge
#18
[Image: ldforge-win7.png]

You guys cannot possibly comprehend how painful it was to get this built under Windows... Qt only added proper OpenGL w/ MinGW builds in a 5.1.0 beta - with what LDForge wouldn't run at all since the GL stuff took right out and crashed... so I had to take the hard route out and compile Qt on Windows. It took me three days in a row to figure this all out and building Qt alone took 2.5 hours.. but it works! .. about time. I was about to lose hope.

I've also fixed the issue with drawing and in the alpha it should be able to draw in all 6 cameras. I also took and added support for external programs so you can launch Philo's utilities we all know and love without having to switch the window and overlays to assist in getting geometry from part images.

At this point I just need to rebuild Qt again (the debug dlls I got are bout 500 megs...), clean up a few small things, package the dlls in and then tag the 0.1 alpha. With luck it should be up today or tomorrow. Smile
Reply
Re: LDForge
#19
I once tried unsuccessfully to compile QT on Windows for LPub... So even if I don't understand the awful details, I can easily sympathize Wink
Quote:I also took and added support for external programs so you can launch Philo's utilities we all know and love without having to switch the window and overlays to assist in getting geometry from part images.
Excellent!!!
Quote:With luck it should be up today or tomorrow. Smile
Yeah!!!
Reply
Re: LDForge
#20
Looking really good. I'm getting even more curious now.
I would love to test it.
Reply
Re: LDForge
#23
Alright. It's been 3 years since I first concieved this.. if back then I was told I'd now be releasing this as a C++/Qt/OpenGL application 3 years from then, I don't think I would've believed a word. Smile

Version 0.1 Alpha is out: grab the Win32 binaries or the source archive (tar.gz format)

LDForge is released under GPLv3 and CC-BY-SA (for icons). Repository URL is https://bitbucket.org/Artakha/ldforge/ for bleeding-edge stuff.

Some things to note:
  • BFC red/green view, albeit present, isn't always right; it assumes everything is CCW and it fails to catch INVERTNEXT in subfiles. Also it has to draw everything twice so there's a bit of a performance hit.
  • Undo/redo stuff is disabled for now over stability issues, it's scheduled for a rewrite.
  • The camera suffers of gimbal lock. I'm going to try address this for future versions.
Reply
Re: LDForge
#25
Mmhhh...
When I launch it I get a "runtime error" with little information ("This application has requested to terminate it in an unusual way")
Sad
Anything special to do? (Win XP SP3 32 bits)
Reply
Re: LDForge
#26
Hey,

sorry, but the same here (VM Win XP SP3 32Bit and VM Win7 SP1 32Bit):

Quote:Microsoft Visual C++ Runtime Library
Runtime Error!
Program: X:\YYY\ZZZ\ldforge.exe
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Rolf
Reply
Re: LDForge
#27
Strange.. yet ironic, I was exactly ancipitating something like this.

I'll try trigger this problem on some windows machines and try debug if I'm successful.
Reply
Re: LDForge
#28
Turned out this was a packaging issue, a dll dependency managed to slip through..

Re-packaged: new zip here
Reply
Re: LDForge
#29
It launches fine! Going to explore Wink
Reply
Re: LDForge
#30
Great to hear! Have fun with the thing. Smile
Reply
Re: LDForge
#31
Starts fine here too.
I'm gonna have some fun this weekend...;-)
Thanks
Reply
Re: LDForge
#32
OK, wishes, problems I found or things that puzzle me... Many of them maybe already in your todo list, and for sure YOU define your priorities Wink All this in very random order...
- The configure button at 1st startup in the screen that asks for LDraw library does nothing for me.
- I'd like a shortcut and/or toolbar icon to enable/disable BFC view
- Open file seems to always start in LDForge folder. Should start in latest accessed folder imho...
- It seems that I can't open a file whose name or path contains accentuated characters (sorry, I'm French Wink
- Cut and paste between two instances of LDForge? Cut / Copy to place LDraw lines as text to paste into external text mode application?
- Better shading?
- A way to control the split of quad into triangles? what about the inverse joining operation?
- I can create vertices - What can I do with them?
- Edit object applied to vertices start from 0,0,0 instead of vertices coordinates
- What's the rationale behind "radial" concept?
- At one time, LDforge stopped to display anything, I had to restart it to be able to use it again. More if I can reproduce this...
- Ctrl+drag or Alt+drag to pan? Middle button drag is not very comfortable (hurts my finger!)
- I was able to use external apps on my Win7 computer, but it doesn't seem to work on my XP box (nothing happens).
- When I select something in main view, I'd like that the text view jumps to first (or last) line of selection.
- In flat views, I'd like a reminder of axis directions (eg. labels -x, +x, -z, +z in view corners)
- Snapping on existing geometry?

...stopping here at the moment...
Reply
Re: LDForge
#33
Philippe Hurbain Wrote:- I'd like a shortcut and/or toolbar icon to enable/disable BFC view
- Open file seems to always start in LDForge folder. Should start in latest accessed folder imho...
- Ctrl+drag or Alt+drag to pan? Middle button drag is not very comfortable (hurts my finger!)
- In flat views, I'd like a reminder of axis directions (eg. labels -x, +x, -z, +z in view corners)
- When I select something in main view, I'd like that the text view jumps to first (or last) line of selection.
Yeah these could be done.

Philippe Hurbain Wrote:- The configure button at 1st startup in the screen that asks for LDraw library does nothing for me.
It's supposed to trigger that "check for LDraw path" thing, it triggers auto if you search for the directory but it doesn't happen if you type it in... that thing is planned to be just removed.

Philippe Hurbain Wrote:- It seems that I can't open a file whose name or path contains accentuated characters (sorry, I'm French Wink
hm. Never took accents into account.. I'll bet it's an issue with encodings.

Philippe Hurbain Wrote:- Cut and paste between two instances of LDForge? Cut / Copy to place LDraw lines as text to paste into external text mode application?
Hrm. Could consider this otherwise but why do you need two instances open? Multiple file support is on the list if it's about that. Exporting selection into text files is certainly doable though.

Philippe Hurbain Wrote:- Better shading?
The lighting sucks, I know. Tongue
The GL renderer's drawing method in general is kinda clunky and just uses display lists, but getting that to already work was quite the effort.. maybe there'll be better lighting/shading if and when I get to know more about more advanced GL techniques.. for now this'll have to do.

Philippe Hurbain Wrote:- A way to control the split of quad into triangles? what about the inverse joining operation?
Sure, whenever I figure how to interface it. For the inverse operation I guess Rectifier already does the job, though if that's not ideal I could try figure some algorithm..

Philippe Hurbain Wrote:- I can create vertices - What can I do with them?
I was planning on making them be drawn on the screen and allow them be snapped to while drawing.. at this point I'm not sure what I'll do with them.

Philippe Hurbain Wrote:- Edit object applied to vertices start from 0,0,0 instead of vertices coordinates

Philippe Hurbain Wrote:- What's the rationale behind "radial" concept?
The point of them was that you could have any sized ring or cone at hand, kind of a model the part now and worry about primitive relations later. Honestly, I've began to doubt their usefulness recently as well.

Philippe Hurbain Wrote:- At one time, LDforge stopped to display anything, I had to restart it to be able to use it again. More if I can reproduce this...
Not much I can do about that unless I get a way to reproduce it.

Philippe Hurbain Wrote:- I was able to use external apps on my Win7 computer, but it doesn't seem to work on my XP box (nothing happens).
Hm.. could it be possible that the paths under XP have accents and Win7 ones don't? I'd see that as the most likely culprit, if not, I'll have to somehow get my hands on an XP system..

Philippe Hurbain Wrote:- Snapping on existing geometry?
Yeah I'd want to do this too but there's more important things to take care of for now. Also I'm wondering what's the most efficient route to take to keep it from being too slow or consuming too much memory..

...stopping here at the moment...[/quote]
Reply
Re: LDForge
#34
Quote:Hrm. Could consider this otherwise but why do you need two instances open? Multiple file support is on the list if it's about that.
Yes, that was the idea. So if you support multiple files, it's fine too. Support of text export is another (useful) thing.
Quote:Hm.. could it be possible that the paths under XP have accents and Win7 ones don't? I'd see that as the most likely culprit, if not, I'll have to somehow get my hands on an XP system..
No, path is pretty simple on both machines: L:\LDraw\Apps\LETGUI\coverer (it's C: on my Win7 one)
Quote:Not much I can do about that unless I get a way to reproduce it.
Sure Wink
Reply
Re: LDForge
#35
Santeri Piippo Wrote:
Philippe Hurbain Wrote:- It seems that I can't open a file whose name or path contains accentuated characters (sorry, I'm French Wink

hm. Never took accents into account.. I'll bet it's an issue with encodings.

I had the same problem with LDCad, the problem is Linux uses UTF8 across the board, but many windows api's (like lowlevel file io) still use the local code page. So you probably have to convert strings before passing them to low level file io functions using 'wcstombs'. This is only needed for window versions. I use an asOSMBStr method in my string class that returns utf8 on linux and whatever the wcstombs returns on windows. You then use the method whenever you need to pass a filename to an api. It's one of the very few functions that needs a different implementation depending on platform.

If you use some kind of string/io library wrapper (NOT plain STD) this should be done automatically though, or maybe it's disabled by default.
Reply
Re: LDForge
#36
I think the problem in question is that I'm passing the strings to the I/O functions directly, from the looks of it they should be converted to QByteArray first to resolve encoding problems. I can make the problem happen even on my Linux system.

EDIT: Hmm, maybe it's better to just drop C-style fopen() and friends completely and just use QFile...
Reply
Re: LDForge
#37
Thought to drop an update, I've rewritten undo/redo handling at this point so in the next version it should be usable. There's also some usability updates plus ability to snap to existing vertices.

Right now I'm in the process of converting the codebase from 8-bit strings and Unix-style file management to Qt-style 16-bit strings and file management which should make things locale-aware. My (hazy) foresight tells me there will probably be a release before the end of June.
Reply
Re: LDForge
#38
Another saturday project later... (mind my system style)

[Image: prims.png]

Yeah it's more savvy about primitives now.
Reply
Re: LDForge
#44
As you can now get these binaries for Windows?
I myself have tried to compile on Qt, but I had a lot of mistakes and could not run.
Reply
Re: LDForge
#45
Fyodor Kolov Wrote:As you can now get these binaries for Windows?
I myself have tried to compile on Qt, but I had a lot of mistakes and could not run.
Sorry for such late a reply, but I cannot really understand what you are saying. Anyway to compile you need Qt4/5 with desktop OpenGL. AFAIK only Qt 5.1.0 and up ships such binaries.

Anyway I've been busy adding some stability to the new features and hope to push another build soon enough. I tried converting the GL renderer to VAOs but ran into a few problems:
  • compiling LDraw object data to vertices is quite the job since there's both triangles and lines, as well as the pick scene and the BFC red/green scene around. need to find out proper optimization for that
  • since all polygons would get chopped down to triangles, the wireframe view would display seams within quadrilaterals

Perhaps I'll try again at some point. I'm certain though that switching to VAOs is necessary should proper BFC red/green view be desired, it's practically impossible with display lists.
Reply
Re: [0.1 Alpha] LDForge
#39
Just a heads up, while a 0.2 release didn't happen yet, I've been doing a good lot of under-the-hood work.. hopefully I can tag another alpha build soon. Also I just moved the repo to Github, in case anyone's interested: https://github.com/slatenails/ldforge
Reply
Re: [0.1 Alpha] LDForge
#41
Will test when I come back home after holidays Wink
Thanks!
Reply
Re: [0.2 Alpha] LDForge
#40
Version 0.2 of LDForge is now released. Main flagship features are vertex snapping and rewritten (and actually usable) undo/redo management. Also, the radial type has been replaced with a simple primitive generator, along with a good load of features and bug fixes.

See full release document here, including full changelog and downloads.
Reply
Re: [0.2 Alpha] LDForge
#42
Update: multiple open file support's mostly up and running, still needs some honing but the basic functionality is there. Smile
[Image: multifiles.png]
Also I'm working on redrawing the icons, hopefully I'll get them done for a 0.3 release as well. I'm trying to make them appear sharper than the current rather blurry ones though I still need to work on the shading and such to make them not appear bland.

Further, J.C. Tchang has updated his excellent LDForge manual, I've mirrored it on my Dropbox: https://dl.dropboxusercontent.com/u/6605...Manual.zip
Reply
Re: [0.2 Alpha] LDForge
#43
Another weekend project done (already...), it can now download parts from the PT. For instance here, the entire EV3 brick Philo recently submitted. It checks through the dependencies and tries to download parts it fails to load.

[Image: ptdownload-1.png]
[Image: ptdownload.png]
Reply
Re: [0.2 Alpha] LDForge
#46
It's been a while without any updates, been mainly testing things as well as trying to get VAO rendering done (it works but I seem to have some conflicts with Qt with it :/), as well as trying to get a better icon theme done, not to mention trying to get overlay images changed into background images (though again I run into conflicts with that)

Anyway LDForge's project file was created exactly one year ago, on sept 22:
Code:
# Automatically generated by qmake (2.01a) Sat Sep 22 17:29:49 2012

So it's sort of LDForge's first birthday, hooray for that. I hope to put out the 0.3 release even if the only big features that would come with it would be the multi-file support and PT downloading.
Reply
Re: [0.2 Alpha] LDForge
#53
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...
Reply
Re: [0.2 Alpha] LDForge
#54
Philippe Hurbain Wrote: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. Smile

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.

Philippe Hurbain Wrote: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.
Reply
Re: [0.2 Alpha] LDForge
#56
Quote:rather glaring bug in 0.2 which causes every 300th line
A nice one, with hair on legs and all Wink
Reply
Re: [0.2 Alpha] LDForge
#57
It's funny enough that it was just a matter of removing 3 characters in the code to fix that...
Reply
Re: [0.2 Alpha] LDForge
#47
This one sure was a challenge to get working, I had to write my own ring finder algorithm, not to mention the hassle with the GUI... but it lives!

[Image: rings-1.png]
[Image: rings-2.png]
[Image: rings-3.png]
[Image: rings-4.png]
Reply
Re: [0.2 Alpha] LDForge
#48
Quote:I had to write my own ring finder algorithm

I am searching for such an algorithm quite a while. Can you share your algorithm with us? So we can incorporate that into other applications as well.
Reply
Re: [0.2 Alpha] LDForge
#49
https://github.com/slatenails/ldforge/bl...c.cpp#L307 -- within LDForge
http://pastebin.com/FPb5Cf7C -- before I integrated it into LDForge, works stand-alone.

This is my current one, although it's a little cheapstake for now. I'm still going to have to improve it so it can find more optimal solutions...
Reply
Re: [0.2 Alpha] LDForge
#50
Thanks for sharing this with us. As I am not familar with the used languages I still have a question before I try to translate this for me (in VB.NT): Can your algorithm also work with decimals? Say outer diameter 23.5 and inner diameter 10.4 ? This is something I am often faced also in the past.
Reply
Re: [0.2 Alpha] LDForge
#51
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..
Reply
Re: [0.2 Alpha] LDForge
#52
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. Tongue
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?
Reply
Re: [0.2.1] LDForge
#55
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
Reply
Re: [0.2.1] LDForge
#58
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)?
Reply
Re: [0.2.1] LDForge
#59
Quote: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.
Reply
Re: [0.2.1] LDForge
#60
Strange behaviour - but thanks for the hint - it works Smile
Reply
Re: [0.2.1] LDForge
#61
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.
Reply
Re: [0.2.1] LDForge
#62
Michael Heidemann Wrote: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.
Reply
Re: [0.2.1] LDForge
#63
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.
Reply
Re: [0.2.1] LDForge
#64
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?
Reply
Re: [0.2.1] LDForge
#65
Roland Melkert Wrote: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.

Quote: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.
Reply
Re: [0.2.1] LDForge
#66
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
Reply
Re: [0.2.1] LDForge
#67
Santeri Piippo Wrote:I'm using VAO though, not VBO.

Yes but VAO is basically VBO++ Smile

For LDraw purposes (especially if you are just drawing single parts) VBO is good enough IMHO. Also not everyone has OpenGL 3.0 available.
Reply
Re: [0.2.1] LDForge
#68
Roland Melkert Wrote:
Santeri Piippo Wrote:I'm using VAO though, not VBO.

Yes but VAO is basically VBO++ Smile
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
Reply
Re: [0.2.1] LDForge
#69
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.
Reply
Re: [0.2.1] LDForge
#70
Alright then, my knowledge must've been really wrong then. I will look into VBOs and get around to implementing them into LDForge.

Quote: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?
Reply
Re: [0.2.1] LDForge
#71
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.
Reply
Re: [0.2.1] LDForge
#72
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.
Reply
Re: [0.2.1] LDForge
#73
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.

[Image: test_render_1.png]
This is the initial view, with the "axes" drawn on the screen..

[Image: test_render_2.png]
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
Reply
Re: [0.2.1] LDForge
#74
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.
Reply
Re: [0.2.1] LDForge
#75
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..
Reply
Re: [0.2.1] LDForge
#76
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)
Reply
Re: [0.2.1] LDForge
#77
Roland Melkert Wrote:Are you sure the correct data is send to vbo?
Yes, I've ensured this with debug printing.

Roland Melkert Wrote: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. Smile

Roland Melkert Wrote:Are all the gl calls returning OK (glGetError)?
hrm... I'm gonna have to check this.

Roland Melkert Wrote: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.

Roland Melkert Wrote: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.
Reply
Re: [0.2.1] LDForge
#78
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...
Reply
Re: [0.2.1] LDForge
#79
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.
Reply
Re: [0.2.1] LDForge
#81
Roland Melkert Wrote: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..
Reply
Re: [0.2.1] LDForge
#82
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
Reply
Re: [0.2.1] LDForge
#83
Roland Melkert Wrote: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!
Reply
Re: [0.2.1] LDForge
#84
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.
Reply
Re: [0.2.1] LDForge
#86
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...
Reply
Re: [0.2.1] LDForge
#87
---
Reply
Re: [0.2.1] LDForge
#85
Roland Melkert Wrote: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
Reply
Re: [0.2.1] LDForge
#80
Are you sure the OpenGL context is current at the time of genBuffers?
Reply
Re: [0.2.1] LDForge
#88
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. Tongue
Reply
Re: [0.2.1] LDForge
#89
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.
Reply
Re: [0.2.1] LDForge
#90
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.
LEGO ergo sum
Reply
Re: [0.2.1] LDForge
#91
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.
Reply
Re: [0.2.1] LDForge
#92
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.
LEGO ergo sum
Reply
Re: [0.2.1] LDForge
#93
Willy Tschager Wrote: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.

Willy Tschager Wrote: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.
Reply
Re: [0.2.1] LDForge
#94
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.
Reply
Re: [0.2.1] LDForge
#95
Just got done writing a magic wand tool:

pre-selection:
[Image: magicwand-1.png]

post-selection:
[Image: magicwand-2.png]

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!

[Image: magicwand-3.png]

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
Reply
Re: [0.2.1] LDForge
#96
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.
Reply
Re: [0.2.1] LDForge
#97
Quote: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)
Reply
Re: [0.2.1] LDForge
#98
[Image: rings.png]
[Image: rings2.png]

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.
Reply
« Next Oldest | Next Newest »



Forum Jump:


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


Users browsing this thread: 2 Guest(s)