LDraw.org Discussion Forums
[0.2.1] LDForge - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: Parts Author Tools (https://forums.ldraw.org/forum-24.html)
+--- Thread: [0.2.1] LDForge (/thread-8711.html)

Pages: 1 2 3 4 5 6 7 8 9 10


Re: [0.2.1] LDForge - Michael Heidemann - 2013-12-21

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.


Re: [0.2.1] LDForge - Santeri Piippo - 2013-12-22

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.


Re: [0.2.1] LDForge - Santeri Piippo - 2014-01-22

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.


Re: [0.2.1] LDForge - Roland Melkert - 2014-01-22

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?


Re: [0.2.1] LDForge - Santeri Piippo - 2014-01-22

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.


Re: [0.2.1] LDForge - Tim Gould - 2014-01-22

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


Re: [0.2.1] LDForge - Roland Melkert - 2014-01-22

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.


Re: [0.2.1] LDForge - Santeri Piippo - 2014-01-23

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


Re: [0.2.1] LDForge - Travis Cobbs - 2014-01-23

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.


Re: [0.2.1] LDForge - Santeri Piippo - 2014-01-23

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?