I have an object in the blender with the vertices and faces, I upload using the loader, and now I want to create particles with coordinates randomly and at a certain speed that the particles move to the top of the object and filled.
I want to get something like this as a result of on this site.
Advise please which way to look, can have libraries that make this possibility even easier.
Related
What’s a good way to have click targets that are larger than the actual scene object?
So far we have been using a larger invisible (yet raycastable) object to do this but it comes at the cost of requiring two draw calls instead of one.
Is there any better solutions?
So far we have been using a larger invisible (yet raycastable) object to do this but it comes at the cost of requiring two draw calls instead of one.
There is no additional draw call if you set Object3D.visible to false. However, you can still perform raycasting against invisible 3D objects. Use Raycaster.layers to selectively ignore 3D objects when performing intersection tests.
So what you are doing is already fine. You might want to consider to raycast only against bounding volumes if the raycasting performance becomes a bottleneck in your app. The idea is to create an instance of Box3 (AABB) or Sphere (bounding sphere) of your actual scene object and only use it for raycasting.
I know that with QObjectPicker I can mouse pick a single entity. But how can I select multiple objects by drawing a rectangle on the screen?
I think this is actually pretty complicated. But here are my two cents:
If you only need to be able to select unoccluded objects
(i.e. don't need to select occluded ones) you could add a second frame graph branch to your existing one and draw each object with a unique color but to an offscreen texture. Then retrieve this texture, check which colors lie within the drawn rectangle and retrieve the corresponding objects and select them (compare to this question/answer).
I'm not sure how well this works in Qt3D because I've always had some issues with QRenderCapture. It didn't seem to have an impact where I added it in the frame graph, i.e. always captured the last state so maybe even if you have multiple render targets it might capture the wrong one etc. Qt3D is still in a pretty rough state I'd say.
If you need an example of how to render to an offscreen texture check out my example on GitHub.
If you need to be able to select occluded objects too
then it gets pretty complicated. I'm just providing some ideas here. I don't know if they will work.
If you don't have that many objects maybe you could implement the idea from above for each single object. I.e. for each object you have an offscreen frame graph branch that filters out all other objects. Then you could check each rendered texture for the rectangle drawn with the mouse. But again I'm not sure how well this works with Qt3D and if you have many objects (like in a game) it will probably crash because of the many offscreen textures.
You could also implement something like "inverse" frustum culling. In frustum culling, you omit rendering objects that lie outside the view frustum of the camera. You could compute a frustum using the rectangle coordinates drawn with the mouse. Check out the QFrustumCulling code. You would need to compute the planes differently of course, using a modified view matrix. When the user draws the rectangle, compute the frustum and check all objects. Unfortunately, this also selects objects whose bounding sphere intersects with the frustum, even though you might visible not touch any part of the object. If that bothers you, you could directly select all objects whose sphere is completely within the frustum and for all objects which only partly intersect do the intersection computation on a per-triangle basis and exit computation for the current object as soon as a triangle intersects the frustum. Depending on the number of triangles this could be very costly computational-wise.
I'd definitely stick to being able to select only unoccluded objects especially because picking in OpenGL seems to be realized by drawing the ojbects with colors these days.
I'm looking for a point where to start and how to do it right. I have a 3d model of an object. On this object are special points. Another thing I have is real photo of this object with source of light
coming from one of the points. What I want to achieve is to in some way comapre this photo and model to be able by basing on source of light to determine what specific point it is.
Which technology/library will allow me to achieve desired result and where I should start looking?
Edit:
To be more accurate. I don't have any data yet. But camera will be placed in fixed position same as metal part. This part will be rotated only in single axis. And this part have different shapes on different angles so it will be easier (I think) to match it with 3d model.
Basically, I want to take a model, create a point cloud of the model and have the models move around. I could populate the models and move them around on the CPU, but I want to find a way to handle the animation on the GPU instead.
So I was thinking of using a THREE.Points object and associating a mesh with each point. I know you can associate a sprite with each point in a THREE.Points object, as seen in this example:
https://threejs.org/examples/?q=point#webgl_points_sprites
Is there a way to associate a mesh (namely, an imported model) with each point, so that I can animate the vertices (and thus, the models) on the GPU with a vertex shader?
Yes there is a way. You should look into the THREE.InstancedBufferGeometry
It's my first time to create an iPhone game. I would like to move a ball, I think there are two ways move an object in OpenGL:
Let each object has a unique glViewPort, then change the origin of
it to move the object.
Let each object has a unique translation matrix.
I did move one object using glViewPort, but not sure if this is the best practice or not.
Whenever you are rendering an object (If you are new, I assume you draw within some glBegin glEnd block) load the GL_MODELVIEW_MATRIX and apply your different transformations on it (Translation, Rotation, Scale). The ModelView Matrix should be set before starting your glBegin/End block.
BTW, it is not a wise idea to move the camera too much unless it is really required.