styxxx Posted November 25, 2015 Share Posted November 25, 2015 (edited) Hi, I noticed the following issue:When creating some objects I can set the renderingGroupId which works fine. Now if I create an Instance of this mesh likevar test = someMesh.createInstance ("testinstance");The created Instance also has the same renderingGroupId as the "original" one. Buuuut it's ignored.Not just for the new Instance, but for the original mesh and all other instances ever created. So for example this code:BABYLON.SceneLoader.ImportMesh("", "objects/", "someobject.babylon", scene, function (newmeshes) { var as = newmeshes[0]; as.renderingGroupId = 2; var tmps = new Array(); for (var x = 1; x < 6; x++) { tmps[x] = as.createInstance ("asInstance_"+x); tmps[x].renderingGroupId = 1; } var testas = as.createInstance ("testinstance"); }});You might expect "as" to be rendered with the renderingGroupId of 2, all of the meshes in "temps" with the renderingGroupId of 1 and testas with 2 (because as.renderingGroupId is 2) or 0 because it hasn't been declared.In fact if you check the values they're:for as = 2, for temps[...] = 1 and for testas = 0;But all the meshes are rendered like having the GroupId 0.Now if you change the value of the latest instance created (in this example testas):testas.renderingGroupId = 2;all the other meshes are rendered with its GroupId although their values stay unchanged. This includes the original mesh "as". If you change the value of any other instance or the "original mesh" the rendering is not affected. This is totally different than with for example "renderOverlay" where changing the value of the original object changes the rendering for all the instances. But changing the latest instance wouldn't affect the original one (actually it doesn't have any effect at all). Also creating new Instances wouldn't affect the rendering of all the other meshes.You can test it with the babylon playground where saving is currently disabled. So here's some code you can copy&paste: var createScene = function () { // This creates a basic Babylon Scene object (non-mesh) var scene = new BABYLON.Scene(engine); // This creates and positions a free camera (non-mesh) var camera = new BABYLON.FreeCamera("camera1", new BABYLON.Vector3(0, 5, -10), scene); // This targets the camera to scene origin camera.setTarget(BABYLON.Vector3.Zero()); // This attaches the camera to the canvas camera.attachControl(canvas, true); // This creates a light, aiming 0,1,0 - to the sky (non-mesh) var light = new BABYLON.HemisphericLight("light1", new BABYLON.Vector3(0, 1, 0), scene); light.intensity = 0.7; var sphere = BABYLON.Mesh.CreateSphere("sphere1", 16, 2, scene); sphere.position.y = 1; // middle // set rendering Group sphere.renderingGroupId = 2; var sphere2 = sphere.createInstance("SphereInstance_1"); sphere2.position.x = 2; // right sphere2.position.y = 1; // renderingGroupId is now treated as 0 sphere2.renderingGroupId = 2; // still treated as 0 since another sphere is created below var sphere3 = sphere.createInstance("SphereInstance_2"); sphere3.position.x = -2; // left sphere3.position.y = 1; // still every sphere is rendered as groupId 0 // After the following statement all meshes are rendered as groupId 3 //sphere3.renderingGroupId = 3; // But this will have no effect sphere.renderingGroupId = 3; // no effect at all //edit: But this will , which is even more strange: //sphere3.renderingGroupId = 3; // all spheres are rendered as 3 //sphere.renderingGroupId = 0; // now all of them are rendered as 0, although setting it to 3 above was ignored - also works with any other value as long as it is lesser than the one given to sphere 3. // Our built-in 'ground' shape. Params: name, width, depth, subdivs, scene var ground = BABYLON.Mesh.CreateGround("ground1", 6, 6, 2, scene); ground.renderingGroupId = 1; return scene;};edit: I noticed something even stranger in the example I created above: setting the groupId to a lesser value works with the original mesh. But nothing else. This doesn't make any sense Edited November 25, 2015 by styxxx Quote Link to comment Share on other sites More sharing options...
Vousk-prod. Posted November 25, 2015 Share Posted November 25, 2015 Does the problem occur in every browsers or only one particular ? Quote Link to comment Share on other sites More sharing options...
Dad72 Posted November 25, 2015 Share Posted November 25, 2015 Hello, The Instances takes into account the basic properties of objects, it can not be changed individually. Trying to create a clone instead. GameMonetize 1 Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted November 25, 2015 Share Posted November 25, 2015 Dad72 is right, instances are rendered in just one draw call. They cannot have different rendergroupId Quote Link to comment Share on other sites More sharing options...
styxxx Posted November 25, 2015 Author Share Posted November 25, 2015 I understand that. But it's about how the render group is mangled The render group is changed when an Instance is created (although the variable stays the same, it behaves as if had changed). Also setting the render group is very weird as you can see in the example code. Example 1:1. Create mesh "original" and set renderGroupId=12. Create Instance "instance1" of former mesh-> original.renderGroupId and instance1.renderGroupId are ignored and both are rendered as if they had renderGroupId=0; Example 2:1. Create mesh "original" and set renderGroupId=12. Create Instance "instance1" of former mesh3. Create Instance "instance2" of former mesh, set instance2.renderGroupId=2-> original.renderGroupId, instance2.renderGroupId and instance1.renderGroupId are ignored and both are rendered as if they had renderGroupId=2; Example 3:1. Create mesh "original" and set renderGroupId=12. Create Instance "instance1" of former mesh3. Set original.renderGroupId=2-> original.renderGroupId, instance2.renderGroupId and instance1.renderGroupId are ignored and both are rendered as if they had renderGroupId=0; Example 4:1. Create mesh "original" and set renderGroupId=12. Create Instance "instance1" of former mesh3. Create Instance "instance2" of former mesh4. set instance1.renderGroupId=2-> original.renderGroupId, instance2.renderGroupId and instance1.renderGroupId are ignored and both are rendered as if they had renderGroupId=0; Example 5:1. Create mesh "original" and set renderGroupId=12. Create Instance "instance1" of former mesh3. Create Instance "instance2" of former mesh4. set instance2.renderGroupId=25. set original.renderGroupId=3-> original.renderGroupId, instance2.renderGroupId and instance1.renderGroupId are ignored and both are rendered as if they had renderGroupId=2; Example 6:1. Create mesh "original" and set renderGroupId=12. Create Instance "instance1" of former mesh3. Create Instance "instance2" of former mesh4. set instance1.renderGroupId=25. set original.renderGroupId=0-> original.renderGroupId, instance2.renderGroupId and instance1.renderGroupId are ignored and both are rendered as if they had renderGroupId=0; It's maybe hard to follow what's happening, in short:- Creating clones resets the renderGroupId for all instances to 0 (at least it's rendered as if this was the case although the varibale stays unchanged). - Only setting the renderGroupId of the last created instance to a higher value has any effect (sets the renderGroupId for all instances)- Only setting the renderGroupId of the original mesh to a lower(!) value has any effect (sets the renderGroupId for all instances), you cannot set a higher value- The actual variable shows a wrong value which does not reflect the renderingI'm using chrome at the moment. edit: the same with firefox Quote Link to comment Share on other sites More sharing options...
Dad72 Posted November 25, 2015 Share Posted November 25, 2015 Maybe it would be easier if you reproduce your example directly on the playground please. Quote Link to comment Share on other sites More sharing options...
styxxx Posted November 25, 2015 Author Share Posted November 25, 2015 I wasn't able to save it to the playground yesterday (an error message about some maintenance mode) but now it seems to work:http://www.babylonjs-playground.com/#CSUQVAll spheres are rendered as if they had renderingGroupId=0. You can play by with the code I commented out to reproduce the effects I was talking about. Quote Link to comment Share on other sites More sharing options...
Dad72 Posted November 26, 2015 Share Posted November 26, 2015 Your link to your scene is not good. Quote Link to comment Share on other sites More sharing options...
styxxx Posted November 26, 2015 Author Share Posted November 26, 2015 Strange. I made another one and fixed the link Quote Link to comment Share on other sites More sharing options...
Dad72 Posted November 26, 2015 Share Posted November 26, 2015 Ok, I simplify your demo: http://www.babylonjs-playground.com/#CSUQV#1 When you change an instance, all instances and the base object takes into account the change. this is normal behavior. Instances are not clones, but references to the basic model that shares the same properties, if one is to change the base object or an instance, all take into account this change. Quote Link to comment Share on other sites More sharing options...
styxxx Posted November 27, 2015 Author Share Posted November 27, 2015 Yes, that's how it should be. But it doesn't behave this way, at least not always. I made a few more examples.http://www.babylonjs-playground.com/#JY2T5#11Here I created a sphere, set the renderGroupId and then created some intances without touching the renderingGroupId. As you can see all the instances and the base sphere are now rendered behind the ground. This means that creating an instance resets the internal renderGroupId. http://www.babylonjs-playground.com/#JY2T5#12Here I did the same. Except this time I changed the renderingGroupId of one of the instances after they were created with no effect. http://www.babylonjs-playground.com/#JY2T5#13As before but this time I changed the rengerGroupId of the base sphere. Again no effect.http://www.babylonjs-playground.com/#JY2T5#14Now I set the renderingGroupId in the loop for every instance. This time it works and all spheres have renderingGroupId=1, including the base sphere (I made a second ground to make it visible). But if I don't set it for every new instance it doesn't work at all:http://www.babylonjs-playground.com/#JY2T5#15In this example I skipped sphere 3. Under other circumstances I noticed that only changing the last instance's renderingGroupId has any effect. Couldn't repdoduce it this time. Sometimes changing the base object's renderingGroupId worked as long as the new value was lower than before. Now it seems that I have to change all instances to the same value, different values has the same effect as setting them to 0:http://www.babylonjs-playground.com/#JY2T5#16(this is exactly the same but I added console logging of the value: http://www.babylonjs-playground.com/#JY2T5#17)This doesn't seem straight. If the value can't be changed for single intances something like "instance.renderingGroupId=2" shouldn't change the variable. Maybe throw an error in the console? Creating new instances shouldn't reset the value for the base element. It isn't the case for other attributes. New instances should inherit the "parents" attributes (but this isn't the case for all, for example isPickable is also true regardless of the base element's value). Changing the base elements renderingGroupId should maybe influence the one of the instances as well. This is the case for "renderOverlay" where changing the base elements value changes the one for all instances, but changing the value of the instances alone has no effect. Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted November 28, 2015 Share Posted November 28, 2015 This is a bug... instances should have the same renderingGroupID as source (And this is not updatable). I'll fix it styxxx 1 Quote Link to comment Share on other sites More sharing options...
styxxx Posted November 28, 2015 Author Share Posted November 28, 2015 Thank you Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted November 28, 2015 Share Posted November 28, 2015 Ok this is now in 2.3 thanks for reporting this styxxx 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.