sgt_barnes

Woha, difficult topic! ;-)

I talked to a PNY representative at CeBIT trade fair once, asking the same question. He took the demo CD I brought him, stuffed it in a Computer with two displays attached to two Quadro cards, started our single-context program and moved it to the other display. It worked flawlessly.

That said, I really think that this works only - if it works at all - with cards from the same vendor.

[Edit: typos]

I'm pretty sure you just ran into the "Link-time Code Generation" feature of VS2012. As the name suggests, code generation is done during linking the whole program, not while compiling each source file.

 

This is done to be able to optimize across object file boundaries, which MS calls "Whole Program Optimization". Unfortunately, this considerably slows down builds.

 

Since it is an optimization technique, it should be turned off for debug builds. So to verify that this is in fact the problem, check if the debug build has the same problem. If not, it is probably the Link-time Code Generation.

 

To turn it off, right-click your project in Solution Explorer, and select "Properties". Then, go to "Configuration Properties", "Linker", "Optimization". Change the "Link Time Code Generation" property to "Default". Make sure that you do this for all the libraries in your solution!

 

That should speed up your build again, hopefully...

@The King2:

 

Yeah, that's exactly what I meant.

Try it, and tell us about the results! 

 

@kauna:

 

If I understand you correctly, you suggest some kind of "overlapping" bounding volumes, ordered in a strict hierarchy of their own?

Octrees are pretty efficient, so I don't think that the performance hit of face picking vs. volume picking would be noticeable. And considered you should easily be able to search through hundreds of faces in under 5ms, that should be o.k. for picking objects in a level editor.

 

Note that you can discard lots of faces early, by rejecting everything with a normal pointed away from the camera. Then, project every vertex of all the remaining faces into screen space and pick in 2D. If you sort the hit list for distance to camera, you can even exit early as soon as one of the faces hits.

 

As for the links: Sorry, I don't have any...

Wouldn't it make sense in that case to only consider the presence of bounding volume edges (line segments for the quad tree, or faces for the octree) for subdivision? You would then get nicely subdiveded cubes around the edges, and not within the volume, I think...

 

For picking, it might even be enough if you consider the faces of the bounding volumes, but this depends on the exact usage scenario.

I am not aware of any good x86 assembler book (which doesn't mean there isn't one, of course! ), but I'd like to recommend Alex Darby's "Low Level Curriculum" blog as a good explanation of how compilers generate assembly from C and C++:

 

Low Level Curriculum

 

The link actually references the 10th (and latest, as of February, 2013) installment of the blog, but that's the only place I know of where links to all the previous posts are. You should of course start with part 1! 

 

Hope that was helpful to you!

Yes, of course!
The former binds the current program object (which tells OpenGL HOW to draw stuff) and the latter the current framebuffer object (which tells OpenGL WHERE to draw stuff).
Obviously, the order of the two doesn't matter, as long as you call them both before actually drawing anything.

I think what you mean is called "state sorting": You sort your queue for render state.

Personally, I strongly believe to keep the engine as simple as possible until it actually runs with all the features you want (which is enough work, for starters). As a single-handed developer, you certainly don't want to waste time with premature optimization, do you? ;-)

Simply add all your objects to one queue and render them in that order. Concern yourself more with culling at this stage of development. Removing an object from the queue altogether because it is not currently visible may well proof to be way more effective than state sorting. Once your code is feature-complete, state sorting is easily added afterward.

So much for preaching, now let's have a look at how state sorting works:

The basic idea is to have a simple representation of the render state of each object (an unsigned int filled with flags, for example), and then sort your queue for this value. Theory says that all objects that require the same render state end up close together in the sorted queue and get rendered consecutively as a consequence.

Note, however, that unless you render lots of (nearly) identical objects it is quite common for all your object requiring different state (that's why I called this technique "premature optimization" previously). Certainly, the orientation and position do normally change with each object, and normally texture maps and shaders do, too. Some Objects may even require different parts to be rendered with different states (think of an otherwise opaque model with only some transparent parts).

Especially transparency introduces another problem to state sorting: It may be necessary to render transparent objects in a back-to-front order to avoid artifacts. But now you end up with two different orders to sort for: screen depth and state. And gone is your simple invocation of std::sort, or how ever it is called in the language of your choice!

To solve this problem, you could split the transparent parts from the object itself and put them in a second render queue. Now first render the opaque things, and after that the transparent parts. First queue sorted by state, second by depth. That would be similar to your queues A and B.

Hope that helped...

Hello Yours3!f,

yes, that would work. But it makes everything needlessly complicated.

You where right when you said that all your quads are the same in object space. But the picking location isn't... ;-)

So what the article meant, I think, was that you could transform the PICKING LOCATION into the object space FOR EACH OBJECT, then perform a simple min/max test with that object. No need to transform four corners just so you end up with a totally ugly general rectangle inclusion test.

Regards,
Tilmann

Hi Jeason,

"Real Time Rendering" is an excellent book! Stick with it!

It certainly helped me a lot in understanding how 3D graphics work. However, I already had a solid math background before I found it, so things like quaternions or transformation matrices where nothing new for me.

If you have trouble understanding everything, I'd suggest that you review the chapters about the mathematical background (that are in the book, IIRC) until you understand everything in these chapters. If these are to hard, google for tutorials on the mathematical topics or try to find books that fit your level of comprehension (perhaps an advanced math school book?).

And I'd like to encourage you to try and implement some of these math things in the programming language of you choice. Nothing lets you understand a problem better than that! And as a bonus, you will also get some kind of math toolkit along the way, which will come in handy later on!

And if all else fails, ask here! If you can ask a specific question, I'm sure all the kind people in this forum are more than willing to help you!

Regards,

Tilmann

edd² already mentioned most of the books that came to my mind when reading your post. You should definitely go for Scott Meyers, "Effective ..." series.

Some further suggestions:

"The C++ FAQ" may be interesting as a further read when you have already learned the basics of C++.

Herb Sutter has kind of a regular column at Dr. Dobbs about threading and concurrency, "Effective Concurrency". Much (if not all) of it is available on the Web. Start here, for example.

The standard read for compiler design is of course Aho, Sethi, Ullmann: "Compilers: Principles, Techniques, and Tools", aka "The dragon book".

Have fun!

I don't want a new configuration.. i want this to all work under debug mode.

Hm, but the preferred way of doing this IS configurations: You would create a new "multi-processor, debug" and copy the settings of your "debug". Now disable "/Gm" and enable "/MP" only for the new config, compile, and there you are: Debugable /MP-Code.

Keep in mind, however, that even when a dll is actually mapped in the same address space as the loading process, it nonetheless has its own heap! So everything allocated (like, with 'malloc' or 'new') by the exe must be freed by the exe, and everything allocated by the dll must be freed by the dll.

This has caused me quite a lot of hadaches!