Jump to content

Visible seam when connecting two smooth shaded pieces.


You are about to reply to a thread that has been inactive for 2249 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

but it should work exactly like that. you used the edge split to make sharp edges. then you make the sides smooth shaded. and finally the adjacent edges of your parts would be welded as wanted. But maybe i did not understand your issue well enough.

However i found some other issues which have to do with the lighting setup in SL. I need to go deeper into this normal stuff again, there is definitively some room for improvement. But i meanwhile believe that i better do the support for custom normal exporting to Collada first, then use that experience to improve the Avastar exporter as well...

Link to post
Share on other sites
  • Replies 61
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

You are in luck! I was just making you a picture. Here it is. At the top is the road section with the extra bits on. These are just additional segments of the curve. That makes the normals at those po

Christhiana wrote: Since I'm also baking a (hi to low poly) normal map with rounded edges, am I correct to assume that if I unwrap the "added parts" to an empty place on (or even outside) the UVma

i can confirm that Avastar calculates the welding wrong in certain situations (however, it works for welding head/upper/lower body of the SL Avatar). Your solution perfectly matches to what i found in


Gaia Clary wrote:

but it should work exactly like that. you used the edge split to make sharp edges. then you make the sides smooth shaded. and finally the adjacent edges of your parts would be welded as wanted. But maybe i did not understand your issue well enough.

That is exactly what I did. All is well until I add the edge splits. For some reason then the result is as in the image at the bottom of this post.

However i found some other issues which have to do with the lighting setup in SL. I need to go deeper into this normal stuff again, there is definitively some room for improvement. But i meanwhile believe that i better do the support for custom normal exporting to Collada first, then use that experience to improve the Avastar exporter as well...

It would be great to be able to export the changed per face vertex normals. This would solve the whole problem. Thank you for your great support!

Snapshot_008.png

Link to post
Share on other sites

That IS exactly what i meant, the welding still seems to take place, but there is an additional issue related to the particular light setup. And that's what i need to better understand. i think that i know meanwhile why this (what you see) happens and if my assumption is true then actually the only good way to fix it is to support custom normals (and some additional user work to get the normals to do what you want). But this will take me some time to get it figured out. Possibly i even need to think about an additional normals toolset...

Well, i always have more ideas than i can realise :matte-motes-bashful-cute-2:

Link to post
Share on other sites

"the problem is the bounding box now has the size of the original with added parts"

Yes. I hadn't noticed that before. In my models, the bb has the x dimension set to the original, but the y dimension isn't. Is that the same in your case? As far as my memory of the source code goes, I would not expect that to happen. I recall code that keeps track of the extreme ends of the geometry as vertices are added to actual polygons. So it shouldn't encounter the removed vertices even though they are in the collada file list.

I tried with a simple cube with the extra bits simple extrusion of +x and +y faces, and this didn't happen. Whether I removed the x extension, the y extension or both, the bounding box fitted the remaining mesh, as I would expect. I will have to look into this more closely.

Meanwhile, you could at least make the numbers more convenient by taking advantage of the fact that the extensions don't have to be whole segments. The angle of the cut off ends of the extra vertices can be adjusted so that the expansion is a more convenient number.

extendedbox.jpg

Link to post
Share on other sites

After some experimenting I have found the following:

- I have the opposite with the axis. The y axis is set to the original and the x axis isn't (more findings on this later on).

- The deleted geometry still counts when calculating Li

- Adding extra geometry on the opposite side of the y axis has no effect on the boundingbox.

- extending the original extra geometry on the y axis by extruding has no effect, it seems to remain at the same position.

Now comes the weird part.... When stretching the original extra geometry on the y axis (to try and compensate so it can still snap to a grid) has effect only when stretching it to multiples of a whole meter ( so the total diameter on the y axis is a multiple of one meter). anything less or more has no effect. If it is stretched to a multiple of one meter the bounding box drops the old size on the y axis and updates to the correct size of the model with deleted geometry, fixing the problem. This might explain your result with a cube. I have no idea what this means but I'm sure you will have an "Aha" by moment now :)

 

This is the extra geometry that worked for me:

Untitled2.png

Here you can see how it was the opposite for me:

Snapshot_014.jpg

Link to post
Share on other sites


Christhiana wrote:

Since I'm also baking a (hi to low poly) normal map with rounded edges, am I correct to assume that if I unwrap the "added parts" to an empty place on (or even outside) the UVmap, that seam won't be visible as well?

This is a baked "only" example with default vertex normals. Might be still the easiest option with Blender. Indeed, this works only with ALM enabled.

The meshes inworld with (lower), and without (upper) the normal map.

The lowpoly mesh, and the highpoly mesh. Full circle to maintain the curvature.

Normals01.jpg

  • Like 1
Link to post
Share on other sites

One more question. For the other LODs I will have to do the same thing, but how about the physics model? If it fits the BB of the LOD0, the original physics model with no extensions should work right?

I doesn't. It gets stretched to the extended bounding box. So it doesn't fit and doesn't work at all. If you use the model with the deleted geometry as physics shape, however, it does fit and does work. Hmm. That's all using triangle-based shapes. 

Link to post
Share on other sites


Christhiana wrote:

Ah thank you!

This together with the solution Drongle came up with should have both ALM and non ALM smoothing covered.

Well, if you bake it with default vertex normals, the mesh will need to have default vertex normals in SL as well, or you produce a seam the other way around, so to say. :matte-motes-delicious:

Link to post
Share on other sites

The model is exported with extra geometry which is later deleted manually from the Collada file. So as long as I bake the normal map with the same added geometry present, the Collada vertex normals and the ones used for baking are identical and all should be fine. I will test this later and report back on it.

Link to post
Share on other sites

"I will have to look into this more closely."

Ah. I found the problem. The way the uploader works out the extents of the geometry is to initialise minimum and maximum values for each coordinate using the first point in the list of vertex positions in the collada file. Then as it adds each vertex to the actual geometry, it compares its coordinates with those in the minimum and maximum, and if the new point is outside that range, it replaces maximum or minimum as appropriate.

If all the vertex positions are used in the geometry, that ends up with the extremes of the coordinates in each dimension. However, if the first position in the vertex position list, used to initialise the values, is from the deleted extension, it may lie outside the bounds of the remaining geometry. In that case, that extreme will never be replaced by a point from the actual geometry. That's what happens with my file. The first point is from the extension that sticks out in the +x direction. So the maximum x extent is left at that point, outside the geometry that gets used in the polylist. If I just replace the x value of that point with a value inside the real geometry, the bounding box is now correct.

Whether this problem arises depends on the order of the polys and vertices in the collada file. It's possible you can find a way of changing that within Blender, but meanwhile, there is a workaround, although a bit tricky. If your mesh has this problem, the first position in the geometry must be from an unused extension. You can't simply delete it, because these values are referred to by index in the <polylist>. So instead, you need to replace it with a value that is within the bounds of the used mesh. It can be found at the beginning of a section like this ...

<library_geometries>
   <geometry id="Cylinder-mesh" name="Cylinder">
     <mesh>
       <source id="Cylinder-mesh-positions">
         <float_array id="Cylinder-mesh-positions-array" count="561">2.193989 11.02993 0.6526969 

These are triples of x, y and z values. The red number is the offending x coordinate which I changed to 0 to correct my file. Zero won't always work, as the whole mesh could be one side of zero. You have to look at other points, or check positions in Blender, to get an appropriate value. If the bounding box extends in the y direction, you need to alter the second number, and if in the z direction, the third.

As far as I am aware, there's nothing in the collada specification that says all points in the vertex position list have to be used in the geometry, so that the edited file that has the problem is perfectly legal. So I will report this as a bug. It should be pretty simple to rewrite the initialisation of the extents with the first point referenced from the polylist rather than the first in the vertex position list. So it would be easy to correct. But I won't hold my breath.

ETA. If you want to play with this test case, the files are now in the jira, which is BUG-8987.

 

Link to post
Share on other sites

Thank you Drongle!

 

That's a very clear explanation of how to work around the problem for now and not too much work either. I can work with this until it is fixed in the uploader or until the Blender collada exporter can export custom normals. And as a bonus I learned a lot about how the collada file format works!

I hope LL will decide it's worth fixing this in the collada importer. I will follow the Jira closely.

 

BTW, you finally got me to try Notepad++ and I love it. I should have tried it years ago. :)

Link to post
Share on other sites

I have been playing a bit more with Avastar's welding feature and after testing a bit more i ended up with something that works nicely:Image12.png

The ring at the bottom is made of 4 mesh elements.  i have placed one element on the top of the ring so you can see where the seams are (inside the green circle)  The horizontal faces are all flat shaded. While the vertical faces are all smooth shaded.

I exported the quarter ring element with the options:

 

  • weld edge normals (to enable welding)
  • weld all visible (to take all adjacent meshes into account)

I could not see the issue that you report. So imho your problem should be solvable with normals welding.

However i will now go and look into support of custom normals :smileyhappy:

Link to post
Share on other sites

"However i will now go and look into support of custom normals" :matte-motes-grin:

Excellent. One day I'll have to look into building BLender so I can help. For now I find it too daunting, not least because I haven't found any clear specification of Blenders internal data structures. So meanwhile please accept lots of gratitude on behalf of all of us for you work on this.

Link to post
Share on other sites

This worked for me until I did the edge splits on the top and bottom edges. I need these to make sure the smooth shading only works horizontally. In your example I see the smoothing going both ways so I assume you did not have edge splits on your model. But you're right that time is better spend on custom normal export for now, this would also solve the problem and give us a lot more flexibility with normals.

For now the method drongle suggested gives the proper result for me albeit it being a little extra work.

 

BTW, it's your youtube tutorials that got me started with sculpties and mesh in SL and helped me made sense of blender 2.49. I'd like to take this oppertunity to express my graditude for your efforts and ongoing support! You're aweome! :D

Link to post
Share on other sites

"It's possible you can find a way of changing that within Blender"

In fact it turns out to be very easy! In my file, at least, I just selected everything and did Menu > Mesh > Sort Elements > Reverse, before exporting and deleting the "deleteme" polylist. That worked. Of course it won't work if the last element is also from an extension, but I don't know that that will ever be the case. If it is, then some of the other sort options might work.

Link to post
Share on other sites

Drongle,

I haven't read the whole thread, just up to where you came with a workaround, editing the collada file.

You edit out some geometry right? Can't you just as easily edit the vertex normals instead? There aren't that many in the object in question and as I understand all the vertex normals are listed in the collada file.

Link to post
Share on other sites

I principle, yes you could. You would have to know two things, which normals to edit, and what they need to be changed to. For the first, you have to negotiate the indexing from the <polylist>, finding which normal goes with which position, and using the position to tell whether that's one of the ones you need to edit and which normal you need to put there. Then you have to work out what the new normal needs to be at each of the relevant vertices, which means interpolating between the face normals of the actual face and the imaginary one you will be joining it to.

The curved road section is just about as easy as it gets for that. I think there would be only twelve normals needing editing. More helpful, because the joined edges are in planes perpendicular to one axis, the new normals all happen to be pointing along another axis. So no calculation is needed, just making sure you get it right twelve times. However, even in this case I think that is enormously more demanding and error prone than simply deleting a nicely delimited chunk of text. In more general case, with many more vertices and with joints at all sorts of angles, it would be extremely laborious and difficult, while still only one chunk of text has to be deleted in the alternative.

Of course if it were done in software, the work and potential error would be removed, but I guess that is what Gaia already did in Avastar. If it were required to work on an already exported collada file, I think the hardest part there would be having sufficiently reliable and flexible ways to identify which edges of different objects are going to get joined and where. I don't immediately see how it could be done at all without including in the file both/all objects that need to be joined, or at least surrogates like the extra geometry that I delete by hand.That is then just about as much work in both methods.

Someone could write a simple script to delete the "deleteme" polylist though. That would help people who don't feel comfortable editing dae files. It could easily check for and correct the problem that was extending the bounding box, which is a bit harder than the simple deletion. In fact, it could quite easily remove all the unreferenced data from the float arrays (position, normal, uv) as well, updating the indices in the polylist appropriately.

Hmm. If I wrote it in R, I guess nobody would use it. :matte-motes-frown:

Link to post
Share on other sites

As I said, I didn't read the entire thread, but if Gaia has a solution in Avastar, it's all a bit redundant.

Editing the normals in the dae instead of the geometry would get rid of the bounding box issues, that's why I posted in the first place. No idea if there is a solution or workaround for that too.

Of course for bigger (more geometry) objects or objects with non-orthogonal normals it would be pretty much unworkable.

Link to post
Share on other sites

Drongle, I tried the sorting and it indeed seems to work! It fixed the bounding box without the need to edit the dae file.

However I found a way to make the avastar collada exporter work for my situation without the need for the extra geometry.

As I mentioned before it worked until I did the edgesplits to make the smoothing only work horizontally.

At first I put a copy of the corner on both sides of the original like this:

full geometry.png

I then exported with the avastar collada exporter with the option 'weld to all visible' checked and got a result like this:

Snapshot_008.png

But when I delete all flat shaded faces on the copied corners like this:

only edges.png

I get the desired result as shown in the next image.

Snapshot_007.jpg

 

Link to post
Share on other sites

That makes sense. I guess it must have been picking the wrong one of the normals at that vertex. So that removing them forced it to pick the right one (Maybe that could be fixed in Avastar by picking the most similar normal when the relevant vertex isn't smooth). Good - Now we have ways to do it with or without Avastar. I guess both will be redundant if Gaia gets the custom normal export into the Blender exporter, although the Avastar one may still be simpler.

Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 2249 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...