Tara Stereo camera is an ideal for applications such as Depth Sensing, Disparity Map, Point Cloud, Machine vision, Drones, 3D video recording, Surgical robotics, etc.

]]>I was about to change FboCubeMap::getTextureCubeMap/Fbo::getTextureBase to take an extra parameter:

TextureCubeMapRef getTextureCubeMap( GLenum attachment = GL_COLOR_ATTACHMENT0, bool updateMipMaps = true /* set this to false to prevent auto mipmap regeneration */ );

... and plumb that through from TextureBase on up.

That way you still get the default current behavior but you can opt-in to write your own.

Thoughts?

Also, I'm new to Cinder and not sure how often these things get updated/merged in.

Thanks,

F

George

]]>

Actually this is a misunderstanding of how Perlin noise works. Yes, there is a random vector (gradient) defined for each grid (integer) point, but the gradient (or interpolation of gradients) is not what the noise function returns. Instead, the return value is based on a dot product of the gradient with another vector, P-Q.

For whatever input point P you're evaluating, and for each surrounding grid point Q, P - Q is the vector from the grid point Q to the input point P. So if P is on an integer coordinate, P-Q will have length zero! And therefore its dot product with the gradient vector will be zero. (See Ken Perlin's presentation slide.)

There are more details to it of course, including interpolation, but that's the basic reason why Perlin noise is zero on the integers.

So, there is a reason why the noise function should yield zero on the integers, in principle. As Matt Zucker wrote in his great Perlin noise math FAQ,

So this "feature" of Perlin noise was known by the inventor, and was not considered a problem for his purposes. (His talk "Making Noise" is very insightful and enlightening about how Perlin noise can be used ... I recommend it.) In situations where the zero-pinning at grid points is a problem, Perlin noise may not be the right tool -- or may need to be adapted, as you did.

By rotating the input coordinates, you moved the zero points ("nodes") away from the integer input coordinates. If that's **all** you needed, seems like it would be a little cheaper to do translation than rotation... and you'd guarantee that your input points would *never* be on a node. But yeah, if you need to avoid having the nodes lined up along an axis, rotation is a good solution. Another solution (more expensive) would be to layer (sum) 2 variants of Perlin noise, one of which is translated/scaled/rotated relative to the other. This would avoid having *any* node points. (And you could take that technique further and make fractal noise.)

]]>Please make all future posts and replies there. This forum will remain online for archival and reference purposes only.

]]>Please make all future posts and replies there. This forum will remain online for archival and reference purposes only.

]]>the Kinect is not supported out-of-the-box, but there are Cinder blocks available that add support. See this great website.

Follow this tutorial to learn more about how to use Cinder blocks:

Reminder: we have a new forum, in the future you may want to post new questions here: http://discourse.libcinder.org/

-Paul

]]>Trying to get started with Kinect in Cinder here.

Basic question: where do you define the Kinect class? There's no sign of any Kinect.h around, although the code includes it. Was I supposed to do something special when creating the project from Tinderbox?

Thanks !

Léo.

]]>Thanks for the heads up with the new forum! :)

]]>-Paul

Reminder: we have a new forum, in the future you may want to post new questions here: http://discourse.libcinder.org/

]]>Reminder: we have a new forum, in the future you may want to post new questions here: http://discourse.libcinder.org/

we have a new forum. You may want to post new questions here: http://discourse.libcinder.org/

If you post there, I'll have an answer for you :)

-Paul

]]>