I was trying to use stemkoski's particle engine in my own project (his example of using the particle engine can be found here ). I have received an error of three.min.js:474 THREE.ShaderMaterial: attributes should now be defined in THREE.BufferGeometry instead. After tracking down the source, I noticed that it is the version of threejs he used in his library that is different from mine. Whereas I used http://threejs.org/build/three.min.js, he used a different version (looking into the file, I believe it's version 60 )
What I have tried so far:
Used the three.min.js from threejs.org/build but change the following in the ParticleEngine.js
this.particleGeometry = new THREE.Geometry();
to
this.particleGeometry = new THREE.BufferGeometry();
This pretty much gives me the same errors
Used his version of three.js instead, says renderer.setPixelRatio and geometry.scale they are not functions (Because I used these two functions in my own project)
I solved this by using the squarefeet/ShaderParticleEngine instead of the stemkoski and it works well. I gave anoter piece of information in a previous answer but it was deleted by Brad as considered as not helpful. I believe it was as it says that updating three.js to r79 was not a solution.
Related
I need to replace old version of boost (1.58) with a new one (1.66). But there is an issue with a breaking change that happened since then in boost::geometry library. I have little knowledge in this library. In the code that I depend on (not written by me) function self_turns() is used. As far as I understand it calculates self intersections. In previous version it required 4 parameters, but in the new one it requires 5 (plus 2 optional). New parameter is IntersectionStrategy. I searched a lot but failed to find any documentation or examples of how this can be defined/used. Does anyone know how it should be used now?
You can try to pass a variable declared like this:
typename bg::strategy::intersection::services::default_strategy
<typename bg::cs_tag<Geometry>::type>::type strategy;
(where Geometry is your geometry type, and bg an alias for boost::geometry) as the missing Intersection Strategy
No, there are no samples yet, it is meant to be a public function in the future but currently it is not (and therefore the interface can change indeed).
I need to get the list of co-ordinates for my box2d world- I'm trying to get a wrap around effect so that particles that go off the side of the screen appear on the opposite side. box2d is not well documented for Processing and the only example I could find was in java (I know its the parent language but it needs translating). This is here.
I think the action is here:
private function updateWorld(e:Event):void {
world.Step(1/30,10,10);
world.ClearForces();
for (var b:b2Body=world.GetBodyList(); b; b=b.GetNext()) {
if (b.GetType()==b2Body.b2_dynamicBody) {
if (b.GetJointList()==null) {
if (b.GetPosition().x*worldScale>640) {
b.SetPosition(new b2Vec2(0,b.GetPosition().y));
}
if (b.GetPosition().x*worldScale<0) {
b.SetPosition(new b2Vec2(640/worldScale,b.GetPosition().y));
}
}
}
}
world.DrawDebugData();
}
So I have tried translating this although I get stuck at the point of world.GetBodyList
I assume world is the instantiated box2d world I have created. I that is so, Processing doesn't seem to recognise this. Basically how to I just get an array of all the particle co-ordinates. Should be easier....
Anything you can do in Java, you can do in Processing. But the code you posted is not Java. It's C++. (Edit: George pointed out that it looks like ActionScript. Either way, it's not Java!)
Box2D is the original library, written in C++. Your code is an example of using that library.
JBox2D is a Java wrapper of the C++ library, so you can write Java code that interacts with the C++ library.
Processing is written in Java, so you can use JBox2D in Processing.
Processing also has a few libraries that simplify JBox2D, like Daniel Shiffman's Box2D for Processing or BoxWrap2d.
You don't need to use these libraries in order to use JBox2D from Processing.
You can find the documentation for JBox2D here.
To answer your question, yes, the world variable would be the instance of World you created when you set up your physics environment.
If you're using one of the Processing libraries, the creation of the World instance might be hidden from you. You might have to use JBox2D directly yourself.
I'm using Cocos2d-JS with Chipmunk and I want release a body and a shape. I see in the chipmunk documentation the functions cpBodyFree and cpShapeFree, but I don't know how call them in my javascript code (body.free and shape.free are not defined).
I'm already using space.removeBody and space.removeShape, but I've read that it is not enough (in fact my game gets slow on my iphone after a while because I create and delete a lot of objects).
Any help?
Thanks.
I want to find an image in another image. I already tried a "template matching" approach, but i didn't know how make it invariant to changes in scale, rotation, perspective, etc.
I have read about feature detection and suspect that usage of sift-features might be the best approach. Beside that i need an implementation of using feature detection using javacv not opencv.
Is there any implementation using feature detection or any other proposal for my problem?
If you understand the basics of JavaCV you can look at the ObjectFinder example of JavaCV.
ObjectFinder # code.google.com
This example shows you, how to do the important steps to solve your problem.
Before using the ObjectFinder you have to call the following method to load the non free modules (e.g. SURF):
com.googlecode.javacv.cpp.opencv_nonfree.initModule_nonfree();
Just for completeness. You can use the image feature matching capabilities provided by opencv, described here. There is even a full implementation of a well working matcher with javacv (in scala though, but it's easily portable into java).
I'm trying to do some shader programming on windows. All the code I've been able to find online says you have to use wglGetProcAddress to figure out where these functions are, but i'm not sure what library to link against.
Ben Voigt's answer is nearly correct, with two exceptions:
All OpenGL 1.0 and 1.1 functionality is inlcuded in opengl32.lib, only 1.3 and upwards and all extension must be loaded dynamically.
WGL guarantees that all contexts sharing the same pixel format share identical function pointers. This is an important detail, as otherwise any application using either OpenGL 3.x/4.x or multisampling would necessarily be malformed.
However, in short, forget all this blah blah. Download GLEW and be done in 5 minutes. It just works and you need not care about petty implementation details. Call one init function at program start, and everything is good.
You link against opengl32.lib to get wglGetProcAddress. All the rest must be dynamically obtained via wglGetProcAddress after you have made a context current, since different contexts can use different implementations of the various functions.
An extension loader such as GLee or GLEW can do the function-pointer details for you, but you still need to be linking opengl32.lib.