Jump to content

From Blender imported cube's transparency


kurhlaa
 Share

Recommended Posts

I don't see any extra diagonals - remember that squares are drawn as two trianges on a normal cube.  Looks like your normals may be backwards on some triangles (actually it *looks* like cull_face or depth_test is not enabled on gl).

Can you share your exported .babylon in a PG?

Link to comment
Share on other sites

17 hours ago, brianzinn said:

similar issues that were fixed by checking face normals in Blender and using the Blender Render Engine instead of Cycles to check.  If that's not it then perhaps share the blend

All face normals look the same, and "blender render" is a default in my case. My demo blend file attached

scene2.blend

Link to comment
Share on other sites

I took your blend, fixed the light, and added a plane also with the same material.  I got rid of the edgesplit modifier on your cube, & added flat shading thru the exporter custom property.

I also set the clear color, & lowered the alpha a little.  I get similar results from both Blender & BJS.  The colors are not a great match (probably differences in lighting implementation), but cannot produce your results.  The color of both meshes is much less yellow, showing color blending.  transparent.blend

Blender top / sandbox bottom.

transparent.thumb.jpg.bccd161e372fca2e3be8df9f37bf49b0.jpg

Link to comment
Share on other sites

Ok, you never said you were turning off backface culling, and it was not set in the .blend (it is not easy to find where).  To isolate between a material problem, I just set the mesh builder box to the material from the export.  It is a geo issue.

The exported cube has 36 vertices (6 per side, which is correct for flat shading).  I turned on debug, switched to meshes section.  When I click mesh builder box, I see properties I have never heard of set ('hasVertexAlpha', & 'infiniteDistance').  The exported cube has no values for these.  I am not really sure what I would even set them to, based on the blend.  @Deltakosh, should these not have a default when not in a .babylon?

Link to comment
Share on other sites

Ok, first I just added those in the PG, and did not fix, so forget that.

The meshbuilder only had 24 vertices, so I changed back to the edgesplit modifier & also switched to no back face culling.  I exported with the latest addin & pasted with line breaks for more readability.  Same result, so I did a run where I also wrote what the meshbuilder had for positions, normals, & indices to console.  Here is a PG with the results of the console logs are in comments.

You will notice that though both positions are -1 & 1, and normals are -1,0,1, the order / indices are not the same.  I did not manually match up the 2 sets to see if they are exactly the same, but you can if you wish.

If you paste the values for the meshbuilder box into the .babylon, you get the desired result.  I do not know why, but it seems this effect is dependent on the order of specify vertices.  The blender exporter writes vertices as they are provided, so I see no way to fix this on my end.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...