Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Jun 2002
Offline Last Active Sep 19 2016 05:41 AM

#5143856 Using Agisoft Photoscan to make 3d Models

Posted by on 02 April 2014 - 03:39 AM

There was a short article in Edge #264 by a small team from poland, "The Astronatuts", which use PhotoScan to model a huge world for their game:




Maybe that helps you a little.


I sadly enough never extracted model data with PhotoScan, the colored point cloud has always been good enough for my purposes...

#5142679 Using Agisoft Photoscan to make 3d Models

Posted by on 27 March 2014 - 03:02 PM

What do you mean with "How accurate can it get?"

Behind PhotoScan stands a surveyor-grade photogrammetry solution. It will easily generate a point cloud with one point per pixel, with milimeter accuracy. You will probably need some experience to make optimal photos to produce optimal results. However, to make really good models from it, manual work will still be required.

They offer a demo license and sample data, so just go ahead and play with it! ;-)

#5139719 Problem with depth test

Posted by on 17 March 2014 - 09:41 AM

Just for clarification: Back face culling and depth buffer are two completely independent features of OpenGL.


I suspect that the two get in the way of each other in your code.


Try to disable back face culling and rely solely on the depth buffer. Is it getting better or worse?

#5128942 FSM libs out there for games?

Posted by on 05 February 2014 - 01:54 AM

"FSM"="Flying Spaghetti Monster", right? wink.png

#5110434 modelview and projection matrices

Posted by on 19 November 2013 - 05:42 AM

Yes, that's possible in principle, but it's not simple.


Basically you just solve the resulting system of linear equations and you are done. 


What makes this hard is that  the system may be massively over-determined.This means, that some equations contradict each other, so you have to find a way of resolving those contradictions.


Google for suitable algorithms, if unsure.

#5062006 Multiple contexts vs single

Posted by on 15 May 2013 - 04:06 AM

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]

#5046852 VS2012 Just Got Slow

Posted by on 26 March 2013 - 07:35 AM

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

#5045541 Octree special case question

Posted by on 22 March 2013 - 02:06 AM

@The King2:


Yeah, that's exactly what I meant.

Try it, and tell us about the results! 




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

#5045288 Octree special case question

Posted by on 21 March 2013 - 09:49 AM

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

#5045227 Octree special case question

Posted by on 21 March 2013 - 06:29 AM

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.

#5037518 Recommend: Assembly Book

Posted by on 28 February 2013 - 03:31 AM

I am not aware of any good x86 assembler book (which doesn't mean there isn't one, of course! dry.png), 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! dry.png


Hope that was helpful to you!

#5012739 glUseProgram and glBindFramebuffer order

Posted by on 20 December 2012 - 02:30 AM

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.

#5010588 Design a render queue

Posted by on 14 December 2012 - 07:02 AM

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

#4994978 2D picking theory

Posted by on 29 October 2012 - 02:41 AM

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.


#4889426 Please introduce me some good books of computer graphics

Posted by on 01 December 2011 - 08:59 AM

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!