babylon Flickering in custom mesh

[masterdon]

Hi Everyone,

I am working on 2D planner. I have this demo http://www.babylonjs-playground.com/#SUXKHY#378I am facing following issue:

1) As you can see i have created custom mesh (window object named w1) on top left corner of design. The code is at

line 369,370.

This window object have y index greater than another slot element(green slots) on top of which it lies. So there is no collision. 

I am aware that mesh border rendering flickers when the borders of mesh collides with each other.but i am ensuring that it is not colliding with object below it. how can i fix flickering ?

2) The text(W1) is created on top of plane having default white color. this plane hides green slots which are behind them. I have tried setting alpha property to make the plane transparent. however it is also changing transparency for text on it. How can i fix this

line 138

[Wingnut]

2 hours ago, masterdon said:

i am ensuring that it is not colliding with object below it.

Hi M.  I'm not believing that.

http://www.babylonjs-playground.com/#SUXKHY#39

Fixed camera to better position, moved renderLayout() into mainline (it had a var in front of it, yet it was outside the scene code, nesting-wise)

I moved w1a and w1b OFF-OF the green wall.  Notice that THEY are z-fighting within themselves (y-fighting, in your case).  Why is there so many mesh... used to make a single window object?  5?  6?  Wow.

But anyway, there is some y-fighting among those 5-6 objects that make a SINGLE window (use control-drag to see sparkling on w1a and w1b).  You need to fix that... before you can test if green wall has y-fighting issue with w1a and w1b window items.  Actually, I think the green walls have some y-fighting, too.  They flicker pretty good... with the mousewheel.

I added a scene.meshes dumper... see console.  Not very handy, because the parts are named "box1", and I can't determine which mesh is for which window/wall segment.  Too many 'box1' 

Sorry if this hurts your feelings, but createWindow() func is out of control.  As you study programming more and more, you'll learn that no function... should be more than about 15 lines of code.  If it gets big, often it can be made "modular".  Your createWindow() func, AND your renderLayout() can both be modularized into MANY smaller, yet nicelyNamedPerPurpose() functions.

When you get modular, and get your indents nice, and get your func scoping mastered, it will be LOTS EASIER for both you and us... to find troubles.  It is very difficult for us helpers to see exactly what createWindow() DOES, because it is a complicated pile of "spaghetti". What if createWindow looked like this...

var createWindow = function(windowOptionsObject) {
     var base = createBasePart(windowOptionsObject);
     windowOptionsObject.base = base;  // take base along... inside suitcase... to all future places
     addFrameParts(windowOptionsObject); // adds more crap to base
     addTint(windowOptionsObject); // adds more crap to base
     // etc.
     return options.base;
}

See how we are calling little do-specific-thing funcs, one after another, and sending a single "suitcase" (windowOptionsObject) as a parameter? 

Each little func... adds another part to the window or base.  It is similar to a "jump table".  See how clean it is to read and troubleshoot?  You can easily turn-off/on these "modules" and that helps determine WHICH little "module" is causing the y-fighting on the windows.  Easy troubleshooting.

Build many little funcs, each well-named, and soon... your code will "read" like a sentence.  CreateBasePart(options), AddFrameParts(options), AddGlassTint(options), etc.  Easy to read, right?  Each function module... receives an options object.... the same one for each module/littleFunc.

You would NOT do this anymore...

             createWindow(horizontalSlotWidth, 0.001, horizontalSlotHeight, -92.5, 54.1, 59, 1.5, 1, 3, 1, 1.5, true, "w1a");
             createWindow(1, 0.001, 6, -96, 54.1, 55.5, 1, 0.5, 3, 0.5, 1, false, "w1b");

You would, instead... do...

w_options = {};
w_options.xpos = -92.5;
w_options.ypos = 54.1;
lots more...

When finished building the w_options object... then do...

createWindow(w_options);

w_options is like a suitcase full of settings and values, and it can be sent to EACH module (each littleFunc) in your createWindow() function.  The w_options suitcase... contains ALL the values needed... to make a complete window.  At first... it will seem annoying to HAVE TO build a complete w_options object for EACH window you want to create, but later, when you want to make a change to a property name, or add new features to your project... you will LOVE the w_options object... because it is so easy to expand or stream-line.

The w_options suitcase-o-values... will become a good friend.  It is like a giant bucket of "everything needed to make a window", and you will find that your window making machine... LOVES IT.  If there are values in the suitcase set to null (such as w_options.tintColor)... then the createWindow() machine (or one of its sub-contractor funcs) can say... "oh, no tintColor... so I'll make the glass perfectly clear".  The createWindow func becomes "smart"... and can check the w_options object to make sure it has everything it needs. 

Then... it starts sub-contracting to smaller companies.   First, goto Ed's BaseMaker shop (take the w_options suitcase).  Next, goto Steve's Framemakers shop (take the w_options suitcase).  Next... Mike's Tinting Shop (take the suitcase).  Farm it out to little funcs... and your code will be MUCH more organized and MUCH easier to read/troubleshoot.

It's called modularizing, and it is a programmer's best friend and lifelong companion.  It will make your code VERY re-usable, too.

But meantime, I think you still have some y-fighting issues.  Good luck.  Try to think about modularizing.  Right now, your code is... umm... scary-big and difficult to read.

PS: I'm terrible at modularizing, but I know it is needed... when projects get XX big.  You... are nearing that point, M. 

[masterdon]

Hi @Wingnut, 

Thanks a lot for quick response(as always) 

I was going to optimize the code(based on some quality checkpoints that i have already listed down) once i am done with achieving the functionality. That is the reason for all this mess. and i apologize for sharing such messed up code. 

I am trying to improvise on all the checkpoints that you have mentioned here. 

1) For windows, I am trying to create a custom mesh. using vertices and faces. instead of using 6-8 sub meshes.  I hope they will help in eliminating the flickering problem.

2) for green slots(non shear walls), some edges are still flickering. though they have not collided with the other meshes. why so?

3) In one of the thread, you have discussed about using 2d lines as borders for boxes. I had hard time implementing that.l failed to scale such lines when camera is zoomed in and out. Do we have any example using meshes with 2d lines that scales down in such scenario.

 

Thanks a lot.

[Wingnut]

  I understand about messy code.  I do the same.  But, difficult for helpers to find problem areas.

#1.  That won't help flickering.  Flickering is from z-fighting (y-fighting).... but... might be caused by edges renderer.  I turned it off, and instead used .showBoundingBox = true;... for NonShearWall, ShearWall, and Corridors.  Still got flicker on green walls, but perhaps not as bad.  http://www.babylonjs-playground.com/#SUXKHY#40

#2.  My theory is that the BORDERS are z-fighting (z and x fighting).   Due to the black border around each wall segment, each is overlapping the black border line of the adjacent wall section (the one next to it).  That is why we ONLY see flickering on the black borders of the green walls (and w1a and w1b, also, but that's later).

The green parts of the green walls... is fine.  No flicker.  But the black borders are x/z-fighting... imho.  The wall segments are overlapping in X and Z axis.  We have been troubleshooting Y-axis overlap... and maybe that is why we are confused.  We have been searching for problems on wrong axes.  Perhaps Y axis is fine... but X/Z... not so good.

There was one other thing I did in #40 PG.  ALMOST every time you used verticalSlotWidth and horizontalSlotWidth, it was followed by a number...  0.001.  I changed ALL of those... to 0.01.  Not sure why.  heh.  I was playing.   

I wanted to make more space between EACH green wall segment.  White-space.  I want to test... IF we had more "gap" between green wall segments... would all flickering stop?

I think it would.  Put gaps in-between each green wall section (if you can), and I think flickering is gone.  (maybe) 

Can you test that?  Do you know how to tell renderLayout() to leave gaps between each green wall section?  Lots of gap/space... so we can see some white background in each gap.  THEN we look for flicker, again.  I think it will be gone.  I think green wall flicker... is caused by black borders X/Z-fighting.  (I said that already, didn't I?) 

#3.  Yes, we can try BJS LinesSystem for borders on wall sections and/or other uses.  It should scale fine.

Lines2D (part of the Canvas2D system) might not work well, because-of scaling reasons (and perspective), as you stated. 

But Lines, DashedLines, and LineSystem should work fine.  They are part of our "parametric shapes" system. 

But... hmm.  I'm not sure that lines are the best way to put borders on the wall segments. 

My opinion?  Use no edges renderer, use no .showBoundingBox, use no Lines borders, use no custom mesh, but instead...  use a black plane (base?) positioned underneath a slightly-smaller green/yellow plane.  If user wants all borders removed (continuous green wall)... then change color on all black base planes... to color of plane ATOP each base (either green or yellow, so far).  The black bases (borders) would SEEM to disappear if user wanted to hide them, but they are actually ONLY changing colors of base planes.

Soooo... your renderLayout would lay-out black bases (at its core/root).  Some bases would have yellow planes atop, some green.  All your "wall items" would start with a black base, and be layered-up from there... using only planes.  The black planes would be slightly larger (x/z) than the green/yellow planes... so that would cause a black border.    Pretty easy.

I know that flickering is driving you crazy.  Sorry.  Don't be discouraged.  We are near-to discovering the reason.    Try to add an easy-settable option to renderLayout()... so you can keep some whitespace between each wall segment... for testing purposes.  Then... we will look for flicker.  Sound ok?  Good luck!  Be well!