Illumination of merged and then instanced mesh

[KevinBLT]

Hello fellow 3D engineers,

 

at the moment I'm working on a replacment of our old 3D system (was a plugin).

I am using babylon for this and I am really impressed so far. The work flows easily through the hands.

So I have a small problem, might be a really small one.

We have a costumizeable pavillon.

 

I build the Roof construction for one side of the roof. (it has a repeating triangular form).

Then merged the mesh, created six instances and rotated them around the center to place them properbly.

The main work is finished (calculation and boolean subtractions). 

Now I just want to polish the scene with shadows etc.

I have already read what to do to sovle the problem with self shadowing (bias value).

But what I see now is that the roof parts a illuminated the wrong for me. 

 

Please look at the screenshot.

 

Is this right? It looks wrong.

I can't say whether this is a bug or I am doing something wrong.

 

Thanks for any help and best regards

 

Kevin

 

[GameMonetize]

Hello and welcome!

 

What do you find wrong?

[Wingnut]

  I see it.  Roof triangles should be brightest... on the opposite side of the roof from the shadow.

 

According to the roof lighting, the shadow should be at about 2 o'clock.  It is at 11 o'clock.  Interesting!

 

Some hooligans must have gotten onto your roof and bent all your lighting normals.  Darn them kids. 

 

Maybe you have ANOTHER light activated, besides the shadow-making light.  *shrug*  Just some thoughts.

 

Welcome to the forum, KevinBLT!  Good to have you with us.

 

PS:  Dk, I hope I didn't ruin some fun for you.    You are probably the MOST meticulous scene analyzer on the entire planet, so, I can't believe you didn't notice the anomaly.  Were you messing-with forum-newbie Kevin and seeing if he could figure-out why his scene was looking strange?  Sorry if I ruined the riddle. 

[GameMonetize]

My questions are always on purpose: Helping people finding by themselves the solution instead of providing the solution for them

 

Here the problem comes from self shadowing. Just set mesh.receiveShadows = false on the roof meshes

[KevinBLT]

Hello.

 

big thanks for your friendly reception! 

 

So now I understood, that the selfshadowing could have confused the roofparts.

I also had one hemispheric light. I turned it off to see what happens.

Also I set receive Shadows to false for the roof parts.

For some reasons it stills looks a bit odd than expected.

 

You can look at the screenshot.

What would be the best option for the shadows and light?

Do I need a hemispheric light? 

The shadow calulation time is not important. It is only calculated one time, when changing something.

After that, I set "renderTargets" to false. Then it only needs to be viewed.

 

Thanks.

I am coming from a 2D Construction and GUI Area and have not so much experience with 3D,

but I am really willing to learn as much as I can  .

[Dad72]

Your problem probably comes from the direction of your light. try using 2 directional lights with opposing directions and a stronger side more light value.

[KevinBLT]

Could you explain that in more detail?

Just a second light at the same position with X,Y,Z *= -1 ?

 

What I found out is, that most things get odd after using CSG and Merging.

Does it swap any normals or something?

For now, I can see it depends on something specific, but I cannot declare what it is.

 

Thanks for any further help everyone.

 

Kevin

[Dad72]

I wrote about the direction of the light and not the position.

 

Here's an example:

var light1 = new BABYLON.DirectionalLight("Sun", new BABYLON.Vector3(-1, -5, -1), scene, true); light1.diffuse = new BABYLON.Color3(0.80, 0.80, 0.80);	light1.specular = new BABYLON.Color3(0, 0, 0);	light1.intensity = 1.2;var light2 = new BABYLON.DirectionalLight("Sun", new BABYLON.Vector3(0.2, 0.1, 0.2), scene, true);		light2.diffuse = new BABYLON.Color3(0.80, 0.80, 0.80);	light2.specular = new BABYLON.Color3(0, 0, 0);light2.intensity = light1.intensity;

All this going on here: (direction of the light)

new BABYLON.Vector3(-1, -5, -1) // direction down with a high value downnew BABYLON.Vector3(0.2, 0.1, 0.2) // direction up (You can increase the values ​​for the shadow is less important on the object.)

[KevinBLT]

Hi folks,

 

I played around and found out that we were near to the solution with brouching the normals.

So they got wrong after these boolean and mergin stuff. I don't know why so far.

 

But I played around and everything goes right again, when calling "MESH.convertToFlatShadedMesh".

I know this can't be the right function, but something inside there, fixes the Problem.

What inside this function could be the fixing spot?

 

And another question to you experts:

What to set, besides the shadow map size, to get the best shadow results?

 

Thanks for now

 

Kevin

[Wingnut]

Interesting KBLT!  I don't think many users have done merging, so we're watching you, and I'm going to adjust the merge documentation as YOU make discoveries.    Sorry I don't have any on-topic answers... but, this is interesting as hell, afaic.

 

But just for fun, let's allow my stupidity to fly once more.  Was the very first roof sub-section (triangle)... made in such a way... that all of its normals... are set to 0,1,0? 

 

(at least I THINK that is a good starting angle for normals)

 

Instancing is good,  but why merge?  Why not make an invisible little box (roof gizmo) and parent all 4 triangles... to the box?  As you likely know, parenting the roof triangles to a central gizmo... still allows you to rotate and position the triangles per the picture. 

 

Maybe they will be parented to "building gizmo".  Want to move an entire hut//building?  Just move the gizmo and the building comes along...intact.     I'm sure you know all this already... sorry.

 

ok, let's see... ummm, I guess that's all I have.  Sorry for the interruption. 

[KevinBLT]

Hello thanks for your reply,

 

so if you're interested, I'll explain what I do in more detail. (The Roofconstruction),

 

There are diffrent Rooftypes for me: Quadratic,N-Edges or a rectangle.

 

Step 1:

• Use scaled boxes as bars and build one side of the roof with the selected options; roof may have some topping or not (Using createBox(), lookAt() and scaling)
• Everything is a bit longer that it must be 
• Everything is a single object (normals should be the way they are when using Mesh.CreateBox)

Step2: 

• Cut (Baylon.CSG) the roof to its geometric figure (a triangle in this case) but just the things that affect this roofside depending on it self

Step3:

• Cut (Baylon.CSG) the roof depending on its global options (overlap, toppings, max height, etc.)

Step4 (this is using merge):

• This is one roofside. It's build in a repeatable way
• Merge the elements that build this roofside
• create instance of this roofside
• place them as needed (in this case: 6 instance rotated around the roof center; six times with 60°)

So I use merge to create instances of a roofside.

In the end I have < 10 draw calls for the scene.

 

Pictures are ordered the way used above.

 

 

Kevin

 

[Wingnut]

Thanks!  Wow, you can almost smell the sawdust and hear the circular saws.    Hard Hat Area!  Nice.  I thought it was a nice little crappy fake hut.  But no... we need a nail apron and a 22oz. Estwing hammer... to get involved here.  PLEASE feel free to talk about your merges in detail... and.... um... add to the docs at will.  (thx) 

 

So cool.  Carpentry!

[Dad72]

So cool.  Carpentry!

 

Yes it is an exciting and noble profession. ca was my first job/training/formation and I did all my furnitures for my house 

[GameMonetize]

Pretty awesome job!

[KevinBLT]

Thanks everyone.

So no it's not a good fake roof 

In this project the realtime creating of everything is an important requirement.

 

So for the things I found out. I think they should be handled by Babylon automatically.

• Before using merge you have to call "computeWorldMatrix(true)" manually or it won't work properbly. I thinkg the "MergeMeshes" function should call it itself if needed (it has the meshes involved)
• When using CSG (which is not as smart as I would it like to have) you have to save the "rotationQuaternion"-Property before disposing the old mesh. The new mesh (csg.toMesh) has forgotten its rotation so you have to write it back. CSG should at least also transfer the rotationQuaternion. But for me the boolean operations should be members of mesh (Mesh.subtract(MeshOther) and so on). And important for work like this: Defining a "cut-plane" where the vertices behind the plane get cut. In this project I always had to define a huge box and even that doesn't always get anything, depending on the size of the objects to cut.
• MergeMeshes and/or CSG change the normals of the meshes. For me: "convertToFlatShadedMesh()" fixed the problem. If this is the default behavior, this sould be called inside mergeMeshes or what ever is the reason for this.
• When placing an object: for example set translation and rotation and then use "locallyTranslate()", it will kill your settings you've just made. You have to call "computeWorldMatrix(true)" before to get the right result. For me the function "locallyTranslate()" should take care by itself, whether the translation or rotation attributes have changed or not and the do the right, because I think setting this attributes and then use locallyTranslate is a default usage for this usecase.

So I would write this into the documentation, if this is an expected behavior, otherwise if should be changed/fixed maybe?

At least the CSG not using the rotationQuaternion thing is a bug for me.

 

Sorry for grammar mistakes I'm in a hurry a bit.

 

Kevin

[GameMonetize]

some updates:

* MergeMeshes will call computeWorldMatrix for you

* csg  will now support rotationQuaternion

* locallyTranslate will call computeWorldMatrix for you

 

 

Thank you for these great feedbacks. They will be on the next commit

[KevinBLT]

Thanks everybody.

 

I appreciate that.

So errors are corrected so far.

 

But does anybody know what changed the normals and/or why?

And why is convertToFlatShadedMesh() fixing it?

 

 

Kevin

[JCPalmer]

some updates:

* MergeMeshes will call computeWorldMatrix for you

* csg  will now support rotationQuaternion

* locallyTranslate will call computeWorldMatrix for you

 

 

Thank you for these great feedbacks. They will be on the next commit

maybe mark not in sync better than compwrld call all over the place.