• Content count

  • Joined

  • Last visited

  • Days Won


Wingnut last won the day on January 18

Wingnut had the most liked content!


About Wingnut

Profile Information

  • Gender
  • Location
    Bessemer, MI, USA
  • Interests
    3D Web, CSS, HTML, Guitars, NORML, storytelling

Recent Profile Visitors

2,465 profile views
  1. Pivotal! Truly pivotal! Hi guys. I have been doing a little reading in pursuit of silhouette things. (okay, okay, that link was for FANCY silhouette things) Can you imagine drawing-on three Shape2D and having it create a model from them? Cooooool. But that's for smarter people than I. My quest... is somewhat more simple. I want to have an extrusion or displaceMap... that follows the outside edge of a transparent-background image. Like this... (truly pivotal) Doors, flat hockey players, what's the difference, right? Create a mesh... extruded/displaced the same thickness across entire surface... and the outside edge "shape" follows the outline of an image (non-transparent part). Cool! SO, I went experimenting. (uh oh). I took the "birdData" from our PolygonMeshBuilder feature... and I stuffed it into the "shape" array of a @jerome extrusion thing! I had to fiddle with the string, a bit, but it's working pretty good! NASA, we HAVE EXTRUSION! (At my age, extrusion is rare... ahem.) ANYway... set line 73 to 1, 2, or 3... to turn-on the extrusion "caps". I think this shape is a little too complicated for the extrusion's capping system... but it gives it one hell of a try, eh? Notice that the capping system is attempting a wagon-wheel-type of capping, from a central hub-point. Our bird says "You'll have to do better than that, if you want to cap ME, buddy" That's a different issue, though. Would anyone like to build an image "outer edge detector"... that creates arrays of vectors... that approximate the "outline" of that image? Vector2 would be fine, but Jerome's extruder uses Vector3's with 0's in the z-component. All in all, I would love to have an "image-outline-to-extrusion-shape" thing... converter... shape generator... you know. Something that makes bird shapes from transparent background bird pictures. Transparent colors in the middle of an image... can be ignored. I just need that outer edge of the image... converted to extrusion shape data. THAT... would be cool. A bottle of whiskey (not too expensive, please) to anyone who can do it for us. Party on, everyone.
  2. Hi J! Yes, that is perfect. But viewport2 will go behind html... because... you know... we can't make a viewport in one corner only. Or, HTML section could be covering a viewport 3. It doesn't really matter. Having it cover the bottom part of viewport 2... would be less work. I think you understand this. (it's because of how viewports are positioned) Another problem might be... keeping absolute-positioned HTML... "docked" to the right screen-edge. Resizing screen can cause problems for absolute positioned HTML. It is important to set, .height, .top and .left... with percentages, and not "pt" or "px" values. Margin settings are ignored for absolute-positioned HTML, I think. Thanks for info about RTT on Canvas2D prim. You tried it / thought-about it, huh? Cool! Likely, it would need to use a special Sprite2D or Shape2D with constant update from RTT. Probably not yet invented. Wouldn't it be great... if we could "feed" an html <img> element... with a renderTargetTexture? Then, the whole right sidebar would be HTML stuff. No viewports or canvas on the right. Perhaps mon1 could be a HTML <canvas> element (with context-2d, not context-3d). hmm. That would also allow us to have an ALL-HTML right sidebar. Perhaps, doing that is a security issue. Not sure. I think I might have tried that before, and failed. But I fail often... and sometimes unnecessarily. Ok fellow forum helpers... here is "The Juan & Wingnut Challenge of the Weekend"! Use a camera view or renderTargetTexture... to fill an EXTRA context2d HTML canvas. Essentially... we need another HTML canvas (or <img> element)... below the renderCanvas area (for our tests). That <canvas> or <img> must be constantly updated from a renderTargetTexture. CAN IT BE DONE? I dunno. Here's a starter playground with 4 HTML <canvas> "monitors" under the renderCanvas. First person to get a RenderTargetTexture... continuously displayed on one of those context2d canvas (canvai?)... gets... A BRAND NEW ROLLS ROYCE! everyone's love and appreciation. Alright! Thanks for all attempts, comments, successes, miracles, etc. I think what we are trying... is a browser security violation. So even if someone DOES do it successfully, we would probably need to report it to the W3C, and then they will change the browsers... and make it quit working.
  3. Hmm. Ok, if you set... scene.beforeRender =()=> { - set all scene.meshes to .setEnabled(false); - activate background layer - delete/null scene.beforeRender; } - wait however long you wish - setTimer - set all scene.meshes to .setEnabled(true); return scene; I have no idea if that would work (or why you want this). But, after the very first run of scene.beforeRender, we delete it... clear it out, null it to nothingness... so it doesn't run again before the next frame. During that one run, it disables all mesh, activates background layer, and self-destructs. Then you can fiddle around with timers or whatever else you want to do... and re-enable all mesh at your leisure. *shrug* Again, not sure. Might explode and kill the cat.
  4. haha. Yuh, keeping a plane (mon1) that is parented to camera... docked against a screen edge... no matter the viewport size... is a serious challenge (somewhat difficult), I suspect. I'll need to think about that issue for a while. That's a brain challenger. I suppose we could use an extra viewport along that right side. With the added along-right-screen-edge viewport, the right side "menu" would be a PERCENTAGE-of-total-screen-width... wide. For example, right viewport could be 20% wide... but... I don't think it could "mix-in" with any HTML sidebar you have over there... UNLESS... that HTML sidebar was absolutely positioned. In other words, you MIGHT have a viewport along the right side of the screen... that is 20% wide... but it will likely be 100% tall (because of the way viewports are defined). SO... let's say you wanted mon1 at the top of that area. With viewport camera and RTT positioning, you could put it there, at the top of the new viewport. And then if you want HTML stuff UNDER that (including things like datGUI panel)... then that html would be absolutely positioned ATOP part of the new viewport (perhaps below mon1). The HTML part of the right side menu (if there IS HTML on that menu) would sit atop part of the canvas of the new viewport. I don't think you can add a viewport like this... ******************************** * * * * * * * *********** * * * * * * ******************************** So, instead... and because of the way viewports are defined/placed, you might do this... ******************************** * * * * * * * * * * * * * * * * * * ******************************** and then absolutely-positioned HTML area covers bottom of new viewport, for example... ******************************** * * * * * mon1 * * *********** * * * * * HTML * * * * ******************************** HTML area covers bottom canvas area of added viewport. *shrug* Might work okay. IF menu is NOT HTML, but instead Canvas2D primitives, then no problems at all. Lower section of new viewport can be filled with Canvas2D buttons, labels, dials, knobs, everything, and no absolute positioning of HTML needed at all. There would be no HTML. In fact, even mon1 might not be a plane anymore. It might be a Canvas2d primitive such as Shape2D or Sprite2d. You might be the first person EVER... to use an RTT (renderTargetTexture) on a Canvas2D primitive. WOW! ---------------------------- Now, about the specularColor on mon1. It is likely NOT mon1.material.specularColor causing the unwanted specular shine. It is likely the mesh.material.specularColor of the scene item that the camera is SHOWING a picture-of. Check out Mon1 is SHOWING a huge amount of secular shine coming from the grass plane. But it is NOT caused by mon1 plane .material, or by camera1 (well, camera1 viewing angle IS a factor). But mostly, it is caused by materialPlane.specularColor and light.specular (both are not user-set, so are currently set to default values). With me? Probably not caused by mon1.material. It is likely caused by the material on the mesh that is doing the specular shine. Weird, huh? *nod* Easy to get confused. Now you have a ton of new things to think about, and so do I. Perhaps others will comment. Be well. Oh, you want to see a multiple viewports demo? Okay. Believe it or not, there are FIVE viewports, there. Even the thin blue lines are in thin viewports. Lines 26-49 carefully divide-up the canvas into sections... all measured from lower left corner (0,0) to upper right corner (1,1). Notice that the upper viewports each use 50% of screen width, no matter how wide the screen. Percentages. Viewports are kind of strange, but very useful in some situations.
  5. canvas2d

    Thanks guys!!!
  6. canvas2d

    Ok, very good, thanks. Good reminders (relatedTarget, isPickable, etc). I forgot that Text2D is "generating" over/out events, even if I'm not observing any Text2D. Its parental rect2D observer was hearing Text2d's bubblings... as you stated. Yep, yep, yep. New demo: It's all working perfect, and just like you said it would. New enhanced console loggings on this one... showing more info. ONE minor thing... I thought I should mention. Currently, (in the new demo) the left button Text2D is NOT producing bubbled overs and outs, and it is caused by line 13. Line 13 is a size setting on the rect2d. You'll notice there is also a size setting on the Text2d in line 21, currently disabled. ONLY when there is a sizer on the rect2d... does the text2D fail to bubble over/out events to rect2d. Here's the truth table: Line 13 active ONLY: no Text2D over/out bubble to rect2d. Line 13 & 21 active: Text2D bubble - > rect2d okay Line 21 active ONLY: Text2D bubble - > rect2d okay Line 13 & 21 disabled: Text2D bubble - > rect2d okay Okay, that's it. I could be mistaken. No big deal... just thought I'd tell you about this interesting sizing thing. Again, good work. I'm having a blast torturing this. It's pretty solid. I'm having difficulties making it screw-up. Don't drag that playground editor/canvas divider bar, though. I probably need to find a refreshAfterResize() or something. I should read the docs someday. :/
  7. Oh yeah! It bangs off the wall real good. I managed to land it atop the wall, butt-first. The tail rotor is on one side of the wall, the skids on the other, and the heli is looking almost straight up. The tail rotor is whackin' on the wall, making everything shake. Too good. ALL the small animals have run and hidden. I wonder if it will fly out of this situation. Congrats on the decent impostoring!
  8. Lime juice? How uneventful. (Wingy adds a big pile of whipped cream... atop his lime juice, and sprinkles-on edible glitter) Yeah, um... me thinks you need to move the rtt cameras... to a .position just behind each window. Maybe? Your vision is so damned big, my brain is having a difficult time holding it in view. Maybe the rtt camera for a given window, should be just outside that window (aiming at skybox). But yeah, .fov and .fovMode could be important here. .fovMode is used to determine if .fov should be applied to height, or to width... I think. Forum search link. Also, I don't know what happens when a camera is set to orthogonal mode, but that might be worth studying, too. In general, though, there's all sorts of trickery and foolery available. There's some extra things that you would need. For example, as player moves around inside the house-o-fake-windows, what do the rtt images do? Do they scroll a tiny bit? Do you need to slightly rotate the rtt cams... so they show a slightly different section of the skybox images? Little things... calibrating. That's how you would get the best fakery. And, you can make your windowed walls out of 4 planes, so there's a REAL hole in the middle. Or use CSG and boolean-subtract a hole into a wall. But, there's still something cool about fake windows that are actually big-screen TV's, eh? Don't try to stick your head out-of one, though... and avoid spitting chewing tobacco out of those fake windows. heh [fun!]
  9. Hi S! My comment here... is off-topic a bit, but if you can make adjustments to DOM things on your platform/system.... you have some more possible options. Consider this. HTML <img> or <canvas> elements... have a .style (CSS stylesheet)... and CSS styles have fun things like .zIndex, .display, .opacity, .visibility, etc. Soooooo... You could build your initial HTML doc... so that an <img> element is sitting atop the renderCanvas <canvas> element. Then, when the "blocked" scene is finished, you could adjust the zIndex of <img> and <canvas> ...within scene.executeWhenReady() ...hiding/removing the image and bringing the canvas to front. I don't know if this would work for you, but there are some options, there. There may be other options for custom loading screens... if that is what you seek. Other comments are sure to come, but I wanted to remind you of the possible HTML/CSS-based options. Other forum helpers... this issue is still open... help at will. (thx)
  10. canvas2d

    Excellent! New test playground: Zones look good, well done! Test buttons: - Over/out on the left button/label (canvas.children[0]) - Enter/leave on the right (canvas.children[1]) . Watch console and color changes while passing mouse across buttons (for new followers to this test). A few questions if I may: #1: Over/out events... happen on the Text2D prims (left button only?), even though no observers are assigned on Text2 prims. Normal/expected? #2: The .isContainer settings (lines 76/77) have no effect-upon the Text2d being event-active. Normal/expected? I'm having a difficult time understanding that. Sorry. #3: Should .isContainer affect the automatic or inherited over/out/enter/leave events on Text2d prims in this example? #3b: Should I NOT BE concerned about .isContainer now, because it does not apply to anything in this demo? I've changed this post 5 times now. I was having some problems making the SAVE option work correctly in PG, when trying to save #11. Sorry for temporary bad link. I wonder if lines 63 and 70 are suppose to be mouseEnter and mouseLeave, not pointerEnter and pointerLeave. hmm. Off to the primitivePointerInfo doc to learn. (It's pointer, not mouse. All is cool.) There's SO MANY event names to remember... in my life.
  11. I think you are correct about the instances, G... but I'm not sure. Makes sense. Clones... are different, though. Clones don't inherit their master's material, though. Instances do. *shrug* Ya know, mister G... that there is some HUGE star-field images... laying around on the web, free. If you used a BABYLON.Layer image with .isBackground = true, and... screwed-around enough, you could pan that... well heck... here's a bad version I once made. Potential poor-man's starfield. But then... there's these equi-rectangular things... special images used as single-image skyboxes. That's really something, too. If you could find a public-usable equi-rectangular starfield image... perhaps you could save yourself a few thousand mesh. But real mesh stars/planets ARE cool, eh? SPS (solid particle system)... or ANY particle system... would get you real mesh stars... for minimum byte/load costs. Both solid and standard particle systems... have a function in them... something like startPositionFunction(), and you get to replace that with your own function. Easily. Well heck, I got a "star dome" that I once did... with standard particles... using a custom startPositionFunction(). See the custom startPositionFunction in lines 11-16? It uses a couple other functions stolen from the web... to plot (start) particles in a spherical shape, and it has some anti- pole-clustering features, too. Works sort of ok. See the updateFunction at line 20? That is the OTHER function in particle systems... that folks often "customize". The one in that PG does nothing... but lets go look at version #4. Version 4 (starts at line 21) (myUpdateFunction) still doesn't do much... except... lines 34 and 35... which cause star twinkle extraordinaire. Try changing that *10 to *50 ... in line 35, and RUN again. WOW! Custom particle placing, and custom particle updating. FUN! Particles are low vertices... better bang-for-the-buck than instances, I suspect. But one sad note. Particles don't do godrays. They once did, but that feature was lost in the depth-rendering wars, I believe. Anyway, thought I'd tell you of a few more ways of doing stars... in case you wanted to go experimenting.
  12. set ground.isPickable = false ? *shrug* Ground is intercepting picks? Maybe.
  13. Nobody mentioned HDR in that PG or thread, so I hope it is on-topic. It was mostly about flipping left/right. Equirectangular was used, though. It is an interesting way to do panos. That's all I got. (a reasonably good memory of previous discussions)
  14. canvas2d

    Thanks N! Ok, .isContainer is events-related, and not anything related to scaling children to fit, or wrapping, etc. Roger that. I should have read docs about it. Good news about S9S, too. Sounds fun! One text2d even if the text wraps tons of times? Nice. Re-wrap on resize/re-scale? I hope so. That's gonna rock! Scrollbars on overflow? Or... stretch height to hold all text? Or... heh. I've been down this curiosity trail before, haven't I? I have some kind of obsession/fascination with containers, I think. thx agn for the work/info, N-man.
  15. canvas2d

    Cool. That dynamicTexture wordwrapping demo I mentioned/showed in my last post... really doesn't work very well. context2d.measureText() is not perfect, I read. I guess it is very important to set the font on the context FIRST, and then call measureText(), or else it calculates lengths based on default fonts. And I think YOU mentioned that measuring text length was not easy for Canvas2d things, too. Yesterday, thiendv asked about background images/textures for labels/buttons, and I didn't know if Sprite2d was allowed to have rect2d and text2d children. Later in the day, I tried it, to make a background-textured label. Worked great. In my studies, I noticed you had .isContainer property, and wondered about its purpose. All this made me think about word-wrapping text2d prims... or possibly using a word-wrapping container which dynamically creates more/less text2d children... depending upon how it wraps. If this container was scaled in size, it could add/subtract text2d prims as its children... in order to display the entire "paragraph". I don't know if your .isContainer would ever be used for that stuff... but... I was thinkin'. Or, maybe power-up the Text2D itself, allowing IT to have multi-lines and do its own wrapping? Nah, that probably wouldn't be a good idea. That would be similar to textNodes inside of HTML divs/spans/buttons. Text2D would need to have sub-text objects, and to do wrapping, it would need to adjust its own sub-text children. (It would be a mini container, itself. A container of sub-text objects.) Weird. Word wrapping is such a pain, but for a Canvas2d word-wrapping "smart container", it would be a double-strength pain, I would suspect. But I think users will want it. Have you (or anyone else) heard-of a user request... to use a single Text2d... to display an entire paragraph, yet? I haven't heard one... but it's coming, I'm sure. Be well.