VoyVoda Posted November 27, 2018 Share Posted November 27, 2018 Hello to everyone I have a question again. And I think it's a simple question for you. When you review the following example: https://webshed.royssheds.com.au/# 1- How can you add and remove the screen instantly when you select wall or object from html? 2- How does it instantly reflect the screen when it changes dimensions? So how do the lengths on the ground change momentarily? The key point of my 2 questions is the instant calculation of the page without renewing them. Is there a way to control it 60 times a second? And if there is such a control, does it make the project very tired? Or is there another way? Thanks in advance for your answers. Quote Link to comment Share on other sites More sharing options...
Sebavan Posted November 27, 2018 Share Posted November 27, 2018 I see you still have the same question. Key thing is on a javascript event you will switch babylon objects. What you could do is preload all the different elements during import. All of them will be disabled and on click you ll simply disable the current one and enable the selected one. this way will be instantaneous. Quote Link to comment Share on other sites More sharing options...
Wingnut Posted November 27, 2018 Share Posted November 27, 2018 Hi VV! Hi Bavs. VV - I think you should learn about layerMasks: https://doc.babylonjs.com/how_to/layermasks_and_multi-cam_textures If you think about it, what you seek is "single object mode/view" and "full scene mode/view". In object mode, you actually switch cameras. Only the selected object is rendered in THAT camera's layer. SO, it will "seem like" all other objects except the selected object... will disappear. They did NOT actually disappear. They are still setEnabled(true) and visibility = 1.0. They are simply on a different (rendering) layer. After you select a wall for example, you immediately set the layerMask on THAT mesh... to match the 2nd camera - the "single object camera"... and position that 2nd camera to "feature upon" the selected object. Aim camera AT object, position it near the selected mesh, and maybe light-it-up with a spotlight parented to the 2nd camera. Then switch the user to THAT camera. Then, user can edit object size/scale, and will see those adjustments happen ONLY on THAT object, but it is STILL part of the scene/shed. You can easily code your own custom "observer" to watch-for size-changes on a piece of wall, and trigger a shedRebuild() when that size (or size on any wall/roof) changes. That's sort of advanced observers/notify stuff, but it's still easy to do. Learning observers is super handy and powerful. You DON'T want to allow the user to rotate or position the single selected mesh... in WORLD space. That would cause it to ruin the shape of the shed. You COULD allow the user to rotate/position it in LOCAL space (while viewing single object camera)... but you must "kill" (null) any position/rotation changes that the user made... before returning to "scene view" camera/layer. Or simply call shedRebuild() upon returning to full-scene-view cam/layer... something you will likely do ANYWAY. Just ignore any positioning and rotations that user did while in "single object view/mode". In a way, you are illustrating the difference between object edit mode, and scene edit/layout mode... something that all 3D modeling packages deal-with. Some still say that those two tools... should be separated into different apps. I hope I understood the issue. It sounds like VV needs "single object mode" with editing allowed on THAT object... yet it must update the entire shed WHILE those edits happen, or AFTER it happens, or maybe full-scene could be ALWAYS seen... in a "popup" renderTargetTexture "mini viewport". User could SEE the changes to the full shed... WHILE changing values on one piece of the shed. Just some ideas. I hope I am on-topic. VoyVoda 1 Quote Link to comment Share on other sites More sharing options...
Wingnut Posted November 27, 2018 Share Posted November 27, 2018 Hi again! https://www.babylonjs-playground.com/#1WROZH#67 There's a playground that shows some layerMask stuff, and has 4 renderTargetTextures (views from a camera converted to a texture) mapped-onto some planes. LayerMask was only used for a "special" thing, in this playground. The renderTargetTexture used to make the view on mon1 (in the lower left corner)... is a camera view from the main scene camera. The 4 mons (views) at the bottom of the screen... were visible in the mon1 view, when I first made the playground. I wanted to NOT see the black area and 4 monitor planes... in that lower left corner view. (see my problem... in this PG) Deltakosh helped me use layerMasks... to remove the lower black monitor areas from the view in mon1 (lower left corner). Now they are on a different layer from the rest of the scene. You can change mon1, mon2, mon3, mon4, and butback .layerMask... to 2 (and then RUN again), to see what I mean. Butback and the 4 little monitor planes... are parented to the main camera. That's what keeps them on-screen, rigidly-positioned. Some users have reported that parenting to a camera... causes problems when canvas sizes change/scale. Hitting F12 to open your browser's dev tools... will show the issue, I think. Resizing the canvas makes butback resize/scale badly. Someday I'll learn more. I'm hoping someday, we can "live-feed" a renderTargetTexture... to a BJS GUI rectangle/image. THAT would rock! Or... maybe I just need to invent the GUI renderTargetTextureControl... v1.0 (yeeeeah) By the way, SOMEDAY, you might wish to say goodbye to HTML forms/widgets for editing your stuff. Everything can be done with Babylon GUI... and then you simply go full-screen with your webGL canvas. Do all your GUI... adjusters... sliders... readouts... with BabylonJS GUI. It's pretty nice. It hurts to leave-behind HTML GUI, because we are already familiar with it. But, full-screen 3D canvas... with GUI layered atop... is pretty sweet, too. Design it correctly, and it can look REAL classy. AND, by using BabylonJS GUI, you can eliminate a "scope" issue that happens when handing-off values from HTML scope, to webGL scope. Once you build your GUI with BJS GUI, all DOM-based event hassles... disappear. It just takes some time, and some big piles of GUI-making code. Copy and paste festival... steal BJS GUI from others... easy. Your Roy's Sheds app looks pretty nice, too. Well done! I like it! VoyVoda 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.