ZGameEditor forum

I have managed a way to get a more beautiful sphere created by using a MeshExpression (based on simple geometry).
BUT I've also found a VERY LITTLE bug: when using a MeshExpression even if the expression is clear you get a more "sharp" or visible edge (should be in corrispondance of the values V.Y == 0)

wow that rocs! you sure got your 3d math workin'. I had noticed that same edge thing,. I was playing around with your Pac Ghost equation, the one with the cos offset inverted bottom,. and I got that hard edge line in smooth shaded. I just went with a flat shader to hide it here is a shaded image of it,. . a line runs the whole seam.

p.s. that image is of a level 2 badguy currently in Artificial Nature,. since I basicly copied your mesh equation and then tweeked it to get that guy,. how would you like to be thanked/credited? 'kattle87' is good or your name?

To take a shot in the dark, I think the shader problem occurs because there are 2x the vertices at the edges that show the shading problem because the meshexpression calculates them twice to close the mesh and it doesn't actually weld the vertices that occupy the same coordinates, thus resulting in a hard shaded edge.
Maybe... maybe not

-Yılmaz

ah-ha right you are! This is indeed an edge where a surface of polys becomes a sphere. the question then becomes why when the sphere is created, does it shade proper ?? I suspect it has to do with vertex normals,. perhaps the meshSphere aligns the normals perfectly, where as the meshExpression moves the verteii with no control to normals,. but again, this is speculation as I have not tried to understand the source code. So far I am using flat shading for meshes with this 'feature'.

That's a very nice looking sphere. And that enemy looks great jph!

After a meshexpression is executed the normals are automatically recomputed. The problem with the shading is because of multiple vertices mapped to the same coordinates.

See the image below. Following the visible edge there are two normals going out in slightly different directions (btw, I've added the "normals" checkbox now in next release for displaying normals in designer).

Can the meshexpression be changed to avoid duplicate vertex mapping?

ha! I like the spikey haired ball! Cool normal view mode,. will be fun to look at stuff with,. and will likely help with issues like this., Not sure if those points could be slightly off-set but,. that would likely form a gap,.? What you think kattle your the mesh math guru?

The point is:
You create a sphere.
You create an EMPTY meshexpression after the meshsphere
you get the edge remarked

There's no need to modify anything else so I suspect this is a bug

However I have uploaded a new vers of the file: the sphere is now created in a really much simpler way (I just don't get why yesterday evening I was not able to make it in this way, but today I noticed the solution was very very simple)
computational cost is reduced a lot and the sphere should be now identical to the ones created in external editors.
The old mesh is also present, now named BallMesh1.

BTW: JHP you can credit me both as "kattle87" or "Francesco" and thanks for the thanks

Hi guys,

After discussing some of the procedural mesh generation methods that ZGE has to offer with Francesco on the ZGE IRC Channel ( #ZGameEditor at irc.esper.net ), I believe the crux of the hard edge problem lies in the fact that the MeshPrimitives aren't closed to begin with ( as Yilmaz mentioned ). The most flexible solution would be to enable this.Normal.? access in MeshExpressions. Another approach would be to calculate average normals automatically for vertex points that share identical positions. Even better would be to physically weld vertex points that overlap, but this might be a little more tricky.

*Additionally a angle threshold ( float ) to determine what edges will be smooth / hard on mesh level would be pure luxury

+ Attached are two more primitives, a cylinder and a cone.

K

Edit - Update IRC Channel

You are correct, the original mesh is not closed. The MeshSphere component generate normals for each vertex by taking the direction from the sphere center to the vertex, so vertex at the same position will also get the same normal. After a meshexpression is executed normals are automatically generated by taking the average face direction for each vertex. This makes the normals point in different directions for the duplicate vertex and the hard edge in shading appears. The solution with allowing normals to be modified in a MeshExpression seems good, so I will try that! There will also be a new "AutoNormals" (default on) property that needs to be turned off for meshexpressions that want to modify normals.

still I don't get why an empty MeshExpression should create the visible edge; if nothing is modified, why should normals be different? that's not my main problem however...
I'm facing a BIGGER problem theese days.
This problem is called "exams"...

The reason is that all normals are automatically recalculated after a expression, even if the meshexpression is empty. Good luck with your exams!