• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Wingnut

  1. Wingnut

    Camera mode like freelancer game

    Hi Asagi. My initial thoughts is that there is an invisble mesh parented to the fighter ship... and positioned in front of the ship... SOME distance. Then, something similar to a BABYLON.FollowCamera is targeting that invisible mesh. Notice the followCamera... .lockedTarget property - set the camera's .lockedTarget to the invisible mesh. [a mesh object] .radius property - set the distance that the camera should follow-at. [a positive number] .heightOffset property - to keep the camera a bit higher than ship/invisible-target. [a number - perhaps positive or negative] .rotationalOffset property - potentially useful... just experiment with it. [a number - perhaps positive or negative] .inertia and .speed - also potentially-useful properties. [also numbers, likely positive-only] I would say... 'target' your experiments in this 'direction'. (arr arr arr) Stay tuned, others may reply soon.
  2. Weird. Thx @JohnK. Unfortunately, lines 20 & 21 are being ignored, in your example. Technically, THAT is how it is supposed to look, except without the rectangle control wrapping the stackpanel. It is supposed to be a simple vertical stackpanel of 6 buttons... along the left edge, centered vertically. I think... if the stackpanel control is working correctly, no button vertical or horizontal aligning or sizing... should be needed. At least it SEEMS that stackpanels once worked that way. hmm. Spacer height? I hope that doesn't affect the spacing between buttons in vertical stack panels. @JohnK, did you spurn DK into breaking something GUIsh? heh. (thx for work/reply!)
  3. Hi gang! Newbie Wingnut here again, hope everyone is well. Here begins a massive "chronicle" of "Stupid Stuff That Wingnut Talks About". It will get big and stale, but what the heck. I goof around in 3dMax a bit, and I've seen their massive 'library' of procedural primitives/shapes, and one would think that BJS is destined to have every one of those, plus a few hundred more. Thoughts, anyone? Thanks!
  4. Hi gang! Wingy fighting with some GUI again. ALMOST ALWAYS, I'm the blame... for my GUI problems. I keep staring and testing. Anyway, there is a 6-button vertical stackpanel... and I THINK the stackpanel should automatically set height on each button... so that all 6 buttons FIT into this 50% tall stack. Butt1 is eating the entire stack-space. hmm. Setting button heights (10%-ish) DOES help the vertical "fit", but not perfect. These 6 buttons should vertical size-to-fit automatically, I think (each button having an auto-height of around 17% of stackpanel height). I think there is something wrong with stackpanel's vertical auto-fitter, or something. But, more likely, I'm missing something. Extra eyes/ideas/help... welcomed. thx.
  5. Wingnut

    About the script positioning issue

    Hi guys. This sort-of sounds like a PARENT issue. Let's pretend many tents... erected in a large field. Each tent has things inside it... and some things nearby it (outside). ALL these inside-the-tent and nearby-outside-the-tent mesh/models/lights... could be parented to the tent... "tent1", and then another "sub-scene" for tent2, and tent3. THEN, all positions/rotations/scalings for tent-parented inside/outside tent items... will be "bound" to the tent's position, rotation, and scaling. In other words, move/scale/rotate the parent tent, and all children will move/scale/rotate "proportionally". And, later, if you want to move the hatchet closer to the tent, or rotate it, or scale it, it will be easy... and will stay near the group-parent. Parents... don't have to be a tent. They can be a small plane/box with .visibility = 0; You might name this invisible parent "group1parent" or "group14parent", etc. These "sub-scenes" could be called "families", because of the parent/child relationship. Then, you don't need to separate your JS into separate files or sections. If you want, you can store your "families" in arrays like... var family3pile = [scene.getMeshByName('family3parent'), scene.getMeshByName('hatchet'), scene.getMeshByName('campfire'), etc, etc ]; (in fact, I think there is a mesh.getChildren() nearby that will help build your family "piles". (storage tanks?) See how you are starting to build your own database of families, all within one JS scene? You can create the family array so that the family-parent is always in the [0th] element of the familyPile array (head of the family). So, family3pile[0].position = new BABYLON.Vector3(x,y,z) will move an entire tent/family to a new worldspace location, but all the children will still remain inside/nearby the tent/parent. Easy, eh? Just some ideas. I know you are trying to think modularly... where code must travel WITH the family group. But that is not necessary. Being able to quickly/easily "look-up" a family/parent from your database-o-families... is what you seek. One array could be var town = []; Fill that with family arrays... which are filled with family members (children). heh. You sort of need a "townManager" or "familyManager" object/system. Not separate JS. Instead, one JS that handles/looks-up ANY number of parent/child groups (sub-scenes)... from Buzul's array of arrays (the town tank). Later, you can build a "country tank", to hold many town-tanks... each full of family tanks. (tanks = arrays = storage tanks)
  6. Hi guys. Sorry to interrupt. Testing playground: Ok, for THAT PG, line 70 is an "anti-gravity engine" for red sphere1. Lines 54-57 add mass to gray sphere2... after 8 seconds. *shrug* Red sphere CAN still have impact and recoil (restitution)... but Y-axis gravity-pull, is nulled/counter-acted. Yep, this is true. In #15 PG... - I have set a TINY amount of mass on red sphere (line 32). I think it automatically rounds-up to .01 mass, so the line 72 anti-gravity line is still needed. - The gray sphere2 has no mass. So, I must "pull" the gray sphere2 downward (to test collision with red sphere1). Lines 73/74 do that. Collision works, restitution/recoil works, but it HAS TO HAVE line 32 mass. Remove line 32, activate line 31, and re-run... to test. hmm. Yep, when both physicsBody's have 0 mass... no colliding done. Darn. Ok, now we got a playground for the forum's mad scientists to experiment-with. I think the direction of study will be... trying to teach the physics engine to ignore gravity on a "custom physicsBody". We will probably need to overload the Cannon "body" object with a boolean like ".ignoreGravity", and then teach Cannon how to watch-for bodies with .ignoreGravity = true, and then do special no-gravity processing for those collisions. Erf. Rough. hmm. This would be a for-one-project hack, and not a core-level thing (unless you/we can convince @schteppe into supporting such a thing... in core CannonJS future versions). Anyway, sorry for the interrupt. Continuing with...
  7. Wingnut

    Ambient Light Discussion

    I think ...will override your "good ingenuity" idea. Sorry. I really like the observable idea, to be frank. What's wrong with that? At some point, you'll probably need to get off-of your "material ambientColor should be white by default" -soapbox, and do a little coping and dealing. I think I calculated that the "loop thru all materials" could have run around 871 quadrillion times... in the time you have used trying to justify a rare-usage mod to SM. heh. Just own-up to the power of BJS... to mop the floor with hobby-grade frameworks like 3JS. Leave behind the weaknesses of lesser frameworks, and move-on-up to the pros, eh? (Just havin' some fun, don't take it "heavy", please.)
  8. Wingnut

    What's next?

    Hey, thx for the setInterval idea, DK & Lihis (in pm) MeshWriter is still being discovered, @The Leftover! Does it need some WD-40? Is it getting rusty? How many future hi-tech-looking advertisements and game intros... will fly-into-view text like... "From the Makers of Serious Sam..." (you know, big chrome fonts... big music, lots of hoopla)? Lots to come. Using webGL for those "holy crap" game intros and company ads... is just getting started. No video, no rendering farms, just big chrome-like meshWriter words... smacking users in the face... with blasts of sparkly particles and camera shakes! BA-BOOM... from the makers of Lite Brite... BA-BOOM... comes a game SO amazing... BA-BOOM... that you will forget to pee! All of it, in real time. No video. No post-processing or rendering. It's easily usable on standard webpages (html5 canvas), without a flash player, without a video player... just good ol' webGL. Aren't ya kind of tired of media players fighting over who gets to be "your one-stop media playing app"? That fight has been going-on for 25 years. Realplayer, WinAmp, Win Media Player, VLC, BSPlayer, on and on. Time to wave the white flag and eat some webM and drink some OGG. (What did he say?) WebGL. YUM! Simple and easy, and with enough sparkly particles and chrome-coated fonts/words, we can do some hoopla. Turn on a little John Phillip Sousa, and we got us a parade! YAY! Probably smarter to fly the camera into the words, instead of the words into the camera. Looks the same in the end. Nah, meshWriter better not go anywhere, in case you were thinking of moth-balling it. Its very bright future is sure to arrive. It helps if you remember the days of "cracking screens" and the competitions to see who could do the best "TA DA!" hoopla. Websites will be introducing themselves similar to movie intros/trailers... more and more. I promise. Flying 3d fonts have a big future, I suspect. Wait for the 2nd and 3rd "wave" of webGL fanatics to arrive, and then look at your usage stats. :) You'll have 100 emails per day of feature-add requests... friggin' puppy stampede. heh.
  9. Wingnut

    Ambient Light Discussion

    Yeah, but let's say scene has 20 materials initially loaded. Phuein needs to do the initial loop to set the ambientColors. 5 minutes later, Phuein has to load-in another 20 materials... and has to do the loop again. 10 minutes later, another 20 materials arrive. Another loop thru all the new materials. One could set ambientColors in the loadTask onSuccess(), I suppose... so only the newest mesh/materials would need to be looped-thru. Otherwise, what? An in-project override of BABYLON.StandardMaterial class... that sets default material.ambientColor to user-preferred gray/white? Yeah... custom standardMaterial. hehe. A chunk of extra code in your project. Just extra bytes, but not much perf loss. Borrow the entire StandardMaterial class from and insert into your project code, then modify. erf. Oh wait... another idea. Top of project code: BABYLON.StandardMaterial.registerAfterCreation = function () { this.ambientColor = new BABYLON.Color3(.5, .5, .5); }; That would work, but... nooooo, there isn't any registerAfterCreation() on SM. Why do I talk? I got nuthin'.
  10. Wingnut

    Ambient Light Discussion

    Good discussion. Interesting spirit from Phuein over... A simple addMaterial(somemesh) function could auto-set a default .ambientColor (like .5, .5, .5) on any late-created StandardMaterial. That's not much of a "tinker". It could use the same value that was used in the for-loop mentioned by @V!nc3r. hmm. I guess we need to determine exactly what Phuein means by "tinker" Perhaps, StandardMaterial could allow an options parameter? new BABYLON.StandardMaterial('newmat", {ambient: BABYLON.Color3.Gray()}, scene); What would THAT do for you, P? Anything good? (It likely gave Deltakosh and other material experts... a brain tumor and a Wingnut-disapproving head shake)
  11. Wingnut

    Ambient Light Discussion

    Again, that's exactly what scene.ambientColor does.... except no intensity setting. The intensity is derived from "how much white-ness" is set in each material.ambientColor. (that's sort of badly worded, but you get the drift) But I think I see your point. I think ambientColor is simply "summed" into the final color result. If ambientColor allowed "50%-summed" or "25%-summed or "double-summed", that would be the same as an .intensity for scene.ambientColor. Interesting. Hopefully we'll hear from the designers of material class... soon.
  12. Hi bar10dr, welcome to the forum. Sometimes people position an invisible box/plane inside the sun... as a parent for the orbiting things. Then the sun can rotate however it chooses, and so can the orbiters. If there are many orbiting planets at different orbit speeds, then you can make a separate invisible "orbit pivot" for each planet. Does that look better? There may be other ways to do it, but invisible planet-parents work pretty well. Each planet-parent can rotate a tiny amount, too, so you can have non-equatorial orbit paths.
  13. Wingnut

    Ambient Light Discussion There it is, of course. Let's say we added a property... StandardMaterial.defaultAmbientColor and then changed that line to something like... public ambientColor = (this.defaultAmbientColor ? this.defaultAmbientColor : new Color3(0, 0, 0)); THEN... at the top of your code... BABYLON.StandardMaterial.prototype.defaultAmbientColor = new BABYLON.Color3(.5, .5, .5); That would cause all StandardMaterials that the scene creates... to have their .ambientColor == StandardMaterial.defaultAmbientColor Would that solve anything? heh. Probably not. Just thinkin'. Would it be used often enough to justify the possible bloat? Dunno. I'm not much of a coder. My expertise lies in selling drugs to children. j/k, of course.
  14. Wingnut

    Ambient Light Discussion

    Doesn't scene.ambientColor do exactly that? It offers each material in the scene... the exact same ambientColor/intensity additive. And by-default, all BJS-created materials react the same way to that ambient light (no reaction at all). Some materials could reflect the blues, others reflect the reds, etc... per material-programmer settings on each material. Can I assume that you think all materials should have some gray ambientColor by default? And each should have the same gray, so they each react exactly the same as each other? Wouldn't that add a lot of .ambientColor settings (scene bytes) to materials... for folks who don't want to use ambient light at all? Do you think those people would be happy about the unnecessary bytes and unnecessary scene-load time? If I were me, I'd have all my metals set with ONE shade of gray, all wood to another, all glass to another, all plastics to another, etc, etc. Maybe I'm missing your point, here. (PS: I'm no wizard... I just yammer-on like I am, often). I suppose it was initial core programmer's decision to have all materials zero-reactive to scene.ambientColor... by default. If you would have been the initial programmer of StandardMaterial class, would you have set a default material.ambientColor of maybe 127, 127, 127 (half-gray)? Perhaps that would have been a good idea, but perhaps too late, now... lose backwards compat. *shrug* Let's invite @Deltakosh and others to give more opinions. I'm not the materials expert you might think I am. :)
  15. Wingnut

    Web Game Editor (MMORPG)

    SO, D72... what did you think of the "side kick" idea? (Like Robin is to Batman) Are NPC's, pets, and sidekicks, all from the same base class, ya think? What will cause a pet-up, partner-up, etc? What would break-up this link? For example, if player had a dog for a pet, and then player killed another dog, would that cause a de-pet? You almost need a "Pets & Sidekicks Engine" with its own programming language, so users can program their own "influencing factors/formulas" A robot... could be a pet, too. It could be a combat robot... no fear at all, and always steps-in to defend its "master". But, it constantly seeks Duracells to munch-on... lots of them. Yeah... fuzzy-logic companion bindings engine. Weird. I love thinking about it. My whole world is fuzzy logic. (ahem)
  16. Wingnut

    Ambient Light Discussion

    Well, hmm. Interesting pondering, for sure, Pheuin. Generally, I think you would want to roto-tiller thru scene.materials and add an ambientColor of medium gray to all of them. That's going to burn a hundredth of a second. After that, you ONLY adjust scene.ambientColor, and all the materials in the entire scene... should react to that "master scene ambient light setting", right? That is your scene's ambientLight, yes? no? I watched a lot of cartoons this morning... so, I could be all screwed-up, reality-wise.
  17. Wingnut

    Parenting a loaded mesh rotates it

    Hiya ranagraw! Umm... first... foreach needs to be forEach... I think. It seems so. There, I've done some fiddling-around in lines 18-28. SOME meshes will have values on their .rotationQuaternion or their .rotation properties... when they arrive. IF you parent them to something, they WILL rotate to match the (new) parent... because parents hand-down their .rotation/.rotatationQuaternion values... to children. In SOME models, such as this skull, there is only one mesh. In other models, there are many mesh... and often one "root" mesh at the "top". But "top" is not easy to find, when you load multiple models in a single scene. In complex models, with many "sub-mesh"... those sub-mesh are VERY OFTEN parented to other sub-mesh within the model. SO, when you forEach thru all the loaded mesh, and parent them to a master parent, that will totally mess-up a complex model. What you CAN do... is somehow "find" the root mesh of each model... and ONLY parent THAT to your master parent. scene.getMeshByName() might be a great way to ONLY get the "root" mesh of any model. THAT'S what you want to parent... but IF that root mesh has a .rotation or .rotationQuaternion value when it arrives in the BJS scene, then parenting it to something COULD rotate it. You COULD make the parent.rotation or .rotationQuaternion... an exact copy of the modelroot.rotation or .rotationQuaternion. THEN setParent, and you should see no rotational change. Kind of complicated, eh? It gets easier with practice, I promise. Notice lines 26-27. It refuses to set a new parent... on any meshes that already have a parent. This may help SOME, but... think about ALWAYS somehow finding the "root" to any model... and only parenting THAT to your master parent. In some cases, you may find that you don't need a master parent in a scene... because ALL complex multi-submesh models... ALWAYS have a "root"... and it is often named, so... it is easy to "look-up" in the scene, using scene.getMeshByName(somename). I hope I have been helpful. Stay tuned... others might comment soon.
  18. Hiya A. I think this is normal. Cannon's sphereImpostor is globe-shaped, no matter what. No scaling allowed, on the impostor. Cannon's meshImpostor allows ANY shape, but... Cannon meshImpostors ONLY react against sphereImpostors. So, your flat surface/ground... would need to be the surface of a very large sphere... like a giant planet. Then the 4-tall feuillage2 meshImpostor would bounce against the sphereImpostor planet surface. The boxImpostors in the scene... would likely cause trouble. You can make a "proxy object"... likely invisible... in the middle of feuillage2. Notice bump1, an added physics-active object in the middle of feuillage2. Hide it by removing line 73. It is one solution. Not the best... but it works. Notice how bump1 was created and parented in the middle of other things being created and parented. Code is sort-of wedged-into the middle. This is because parenting should be done BEFORE physics impostor-adding. (I think that is the golden rule, if I rem right). :) All in all, just keep in mind that the "order of doing stuff" is important when making compounds via parenting. I hope this helps. We can talk more, as needed... if/when I'm around. Others may have more/better comments/ideas, so stay tuned.
  19. Wingnut

    What's next?

    Hi gang. I think I will have a need/desire for an "onPointerHeld" event/observable for BJS GUI events. Possible? Would someone consider coding it for me/us? That would be great. IF... onPointerOut could be repeatedly polled WHILE onPointerHeld was active/repeating, that would be nice, too. If user's pointer drifts off-of the control, heldPointer cancels. Case: Momentary (spring-loaded) rocker/toggle switch, with auto-return-to-center/off. When held depressed, it repeatedly/constantly does... something. Extra credit for "repeat rate" (how quickly observer-polled)... but, maybe that is done in the handler (only react to every 10th repeated event, for example). I don't know much about "pointer/button held" things. Does it stream events repeatedly? I have so much to learn. Teachings/corrections welcome, thx.
  20. Alright, my refurbed ipad4 arrived, is router'd, and has installed its latest iOS version. I Safari-browsed a couple of BJS demos... worked ok. Sponza demo... good sounds and scene... but slow turning. Internet Cafe demo... looked good, also slow turning, and browser crashed at the top of the stairs, twice. I will try to investigate further, after I learn to drive iOS better. Might need fresher Safari. Good fun. This pad is bigger and heavier than I expected. And it claimed to be "grade B" quality, but I don't see a scratch on it. (yay). It's purrrrrrdy. Too nice for this "campfires and mud bogging" kind of chap. I need carrying cases, next/soon. I'm also preparing power and mounting devices for... - truck (view truck's PDF owner's manual + use accelerometer to find some jerking. Truck has USB jacks & cig lighter socket. I needed usb to Apple "lightning" adapters for powering from truck USB). - boat (watch movies while fishing) (boat uses 12-volt car battery/trolling motor) (Wagan 9.6 amp 4-outlet charging station will be attached to top of boat battery box) - mic-stand (lyrics/songlists) (wall-wart ipad power) The friggin Arkon heavy duty "ball-stack" mounting arm is $100! OMG! (I found a new-but-scuffed for $45) phew. I think I can use same mounting arm for all three applications. Quite off-topic, I know... but I'm excited! This is my first-ever mobile device, and the first time I've used one. Baby's first swipes, ya know?
  21. Wingnut

    Web Game Editor (MMORPG)

    Cooooool. Nice work, D72! Oh, the pets and NPC AI systems could be SO SO much fun to design. Really, the generated "traits" of the NPC... should determine WHICH faction an NPC is most-likely to "gravitate-towards", eh? Perhaps NPC could also decide to be faction-free, because one of his/her traits is high-independence. Same for "pet NPC's" like girlfriends, boyfriends, and other "non-leashed" sidekicks. For example, a guy NPC might try to "pet-up" with a pretty girl PLAYER... if he has low .independence, and high .attractedToBeauty. The girl will allow none, some, or all "sidekick/pet" attachment, dependent upon HER traits (with choice also being a factor, of course. She's player class.) Also, NPC could follow SOME traits of a faction, or complete devotion to a faction's policies/ways, also dependent upon NPC traits. The NPC could be partially devoted to 2 or more factions, even. Example: NPC likes the way the Quakers think on ONE issue, and likes Buddhist policies on ANOTHER issue. Split devotion. WOW! Then, bring inventory into .likelyhoodOfAttractingCarnivorousPets property. heh. Is player carrying fresh meat? Carnivorous pets would be wanting to "pet-up". Carrying jewels/gems? No smell, and likely hidden, so thieves will not be attracted. If jewels are worn, thieves will be trying to pet-up (sidekick-up), because of attraction. SO FUN! BIG monster AI/petting/sidekick system... takes a year to code! heh Spreadsheet-ish, eh? Each ss cell is a property, with many cells affecting the values of many other cells, via cell formulas. Phew.
  22. Oooh, I can literally "feel" the community-embracing of that challenge, can't you? Ok, so I worked on an old, water-damaged apartment, in trade for some free mason marketeer coupons, and I ordered this... (A 1940's coal-powered iPad 4 with enough memory to store a mosquito fart.) And then I bought one of these... (64 gb ram-drive on a lightning connector) Soooo... I'm going to be touch-screen ready... pretty soon. Then, I got miserable "fungal pneumonia" for 2 weeks, from working on that apartment without using a respirator. Brilliant, eh? See what happens when we "consume" refurbished (pigeon poop) crap? heh.
  23. Wingnut

    Spirographic Particles

    [ Wingnut ponders attaching a followCam to the pen, but aborts the idea until he buys more motion sickness pills. ] :)
  24. Hi @razieh, welcome to the forum. Likely, you will need to convert the HTML menu panel... into Babylon GUI stack panel. Camera-moving funcs won't need to change. Just change the type of buttons... from HTML... into Babylon GUI. 10 minute job. Ok, maybe 30 minutes. StackPanel's aren't the only way to arrange buttons/controls in Babylon GUI 2D. There is also "grid". Here is a SWEET grid example: Good luck. Keep us posted.
  25. Nice work, John! Thank you! I had another thought (with a possible need for such). Does anyone think (sim-) gyroscopes would work... in a physics engine? Here's some fun videos to add to the pondering. Comments/thoughts welcome. I also think we could move-ahead on Fibonacci things... pine cones, cauliflower, conch shells, etc. I LOVE "grown" mesh. Maybe someday we could modify John's spiro-code... so that it always TRIES TO generate ONLY Fibonacci/GoldenMean/Phi spirals. Wow! (1.618-to-1 expansion/contraction ratios?) I tried a "Fib" playground, recently. PS: Just in case you were thinking that the wobbly pole of a child's gyro... draws spirograph flowers or Fib spirals, I think that is not true. But wouldn't it be something if it DID?