I have a task to render images for a given sample size. At first, I add 5 meshes to pyrender scene, render the image, and remove the meshes from the scene. This iteration is continued for the given sample size. However, in the second loop, I get this error
ValueError: Mesh is already bound to a context
Could anyone help me understand what this error means and how I can rectify this? Thank you.
I also encounter this problem.
And I think this is caused by that you have added this mesh to a renderer. After that, if you remove the mesh, the mesh have still been changed in some way(which is "bound to a context")
In my code, my solution is to reload the mesh file.
That will be OK.
Related
I tried the Instancedbuffergeometry, it works awesome,
Intersection is not happening in InstancedBufferGeometry, i checked in the threejs(r85) library, checkBufferGeometryIntersection function have the position value only, I think the offset and orientation value need to use with the position.
I have another doubt in it, i have used one rawshadermaterial only, then how i can highlight the selected geometry.
Can anyone guide in it.
Thanks in advance.
As far as the cpu is concerned (where you do the raycasting) those instances do not exist. You do however have your master geometry available. What you can do is, create another instance of BufferGeometry then create the same number of Mesh objects using that one instance of geometry. Use the same logic for instancing to place this into a scene. You don't render them, thus saving the overhead from multiple draw calls. You do have them available for intersection though as if it were normal geometry, because it is (you're just not rendering it).
As #pailhead already wrote, raycasting with instanced-geometries cannot work.
An alternative approach to achieve the same goal is to use so-called GPU picking. For this you render the scene into a framebuffer, using a special shader that will just output a unique color-value for every instance.
You can then sample the point under the cursor from that framebuffer and compute the instance-id from the color-value.
You can see an example for this technique here or here.
I'm learing three.js and I faced a z-fighting problem.
There are two plane object, one is blue and the other is pink.
And I set the positions using the flowing codes:
plane1.position.set(0,0,0.0001);
plane2.position.set(0,0,0);
Is there any solution in three.js to fix all the z-fighting problem in a big scene?
I ask this problem because I'm working on render a BIM(Building Information Model, which is .ifc format) on the web.
And the model itself have so much faces which are so closed to each other. And it cause so much z-fighting problems as you can see:
Is three.js provide this kind of method to solve this problem so that I can handle this z-fighting problem just using a couple of code?
Three.js has given a general solution like this:
var renderer = new THREE.WebGLRenderer({ logarithmicDepthBuffer: true });
The demo is provided also here:
https://threejs.org/examples/webgl_camera_logarithmicdepthbuffer.html
It changes the precision of depth buffer, Which generally could resolve the z-fighting problem in a distance.
At least for the planes on your screenshot, you can solve that problem without switching to the logarithmicDepthBuffer. Try to set depthWrite on the material to false for the planes. Sometimes you also have to override renderOrder for meshes.
There is an example
.depthWrite Whether rendering this material has any effect on the depth buffer. Default is true.
When drawing 2D overlays it can be useful to disable the depth writing in order to layer several things together without creating z-index artifacts.
.renderOrder This value allows the default rendering order of scene graph objects to be overridden although opaque and transparent objects remain sorted independently. When this property is set for an instance of Group, all descendants objects will be sorted and rendered together. Sorting is from lowest to highest renderOrder. Default value is 0.
What is your PerspectiveCamera's zNear and zFar set to. Try a smaller range. Like if you currently have 0.1, 100000 use 1, 1000 or something. See this answer
https://stackoverflow.com/a/21106656/128511
Or consider using a different type of depth buffer
I just stumbled across z-fighting using multiple curved planes with front and backside textures placed along the z-axis of the scene. Even though depthWrite would remove the artifacts, I kinda lost the correct visual placements of my objects in space. Flatshading did the trick for me. With enough segments, the light bouncing is perfectly fine and z-fighting is gone.
I have a quick question, may be someone will explain it to me.
The scene setup is show below. I have a sprite tree, a cube and a cubeCamera. Cube material has envMap set to cubeCamera.renderTarget. (CubeCamera is places where the cube is, and also i hide the cube before calling updateCubeMap method).
So, the question is why the sprite appears upside-down in the reflection?
This seems to happen only to sprites, other objects behave as expected.
In the actual project we manually flip sprites before updating cubeCamera, and it seems to work ok. But i want to actually know why is it so? Thanks!
UPD. Demo http://webgears.ru/public/wgdemos/spriteInEnvMap/
I'm loading several STL files (one by one) into the same scene. Those files are different LODs of the same model (from low-poly to high-poly). I'd like to simulate a continuous model update from low to high resolution.
I tried to create a separate mesh for each LOD and add it to the scene when removing the previous one. Unfortunately, as the LODs get bigger, there is a significant delay in rendering.
See the example and full code
My questions:
- would it help if I just replace the geometry in the same mesh without recreating the mesh? If so, how to force rendering update? I tried to use mesh.setGeometry, but it doesn't seems to work for STL geometry - the new geometry is shown (perfectly works for Cube, for some reason).
- is it possible to speed up the update somehow by any sort of pre-calculations or caching?
Thanks a lot in advance for any hints.
Simon
My problem seems to be really simple but I just can't get the reason behind it:
I have a vertex and an index buffer that get filled in with glBufferSubData. There are a couple of meshes that get filled in one-by-one into this big VBO and its corresponding IBO
Then I try to render those small meshes with glDrawElements one-by-one
Problem is, only first mesh gets rendered - and multiple times - in places where each of those different meshes should be!!!
Following info may be useful:
I create VBO this way
gl.glGenBuffers(1, buffers_, 0);
gl.glBindBuffer(GL11.GL_ARRAY_BUFFER, buffers_[0]);
gl.glBufferData(GL11.GL_ARRAY_BUFFER, sizeInBytes, null, GL11.GL_DYNAMIC_DRAW);
Then each mesh is filled into the VBO like this
gl.glBindBuffer(GL11.GL_ARRAY_BUFFER, name);
gl.glBufferSubData(GL11.GL_ARRAY_BUFFER, startOffsetInBytes, numBytesToCopy, nioBuffer);
And meshes are rendered in this fasion
bind VBO/IBO and set appropriate client states
then set vertex, normal, and texcoord "pointers" - they point at the beginning of VBO plus their offsets in vertex "structure"
and call gl.glDrawElements(GL10.GL_TRIANGLES, indicesNum, GL10.GL_UNSIGNED_SHORT, startIndexOffsetInBytes);
then finally, unbind VBO/IBO and disable client states
I debugged the code and I'm sure that sizeInBytes, startOffsetInBytes, numBytesToCopy and startIndexOffsetInBytes are correct values (in bytes:))) and indicesNum is the number of indices/vertices in the mesh (to render).
One suspicious place is setting vertex/normal/texcoord pointers - they get set only once - and set to the beginning of the VBO. Maybe I need to set them each time before calling glDrawElements?
:D Found that reason. Everything I described is correct indeed. Problem is in the way meshes are being added into the VBO/IBO - indices for each new mesh were restarted from 0!! So only the first mesh in VBO was getting rendered.