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 - Roland Melkert - 2014-01-23

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.


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

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.


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

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/gl/src/GLCompiler.cc
https://github.com/arezey/ldforge/blob/gl/src/GLRenderer.cc


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

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.


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

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..


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

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)


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

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.


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

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/showthread.php/182314-glGenBuffers-returns-0?p=1253052&viewfull=1#post1253052
hhrrmm...


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

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.


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

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