Sonic_Serpentine

Thanks guys. Wingnut, thanks for pointing out .level. Just played with it a bit on the lightmaps with similar results, but it certainly seems valuable for future tweaks.

Hey guys, So I'm looking into an ideal way to set up lighting for my levels. I'm going with PBR since that's what I'm familiar with from other engines. Right now I'm just leaving reflection color black until my diffuse + lightmapping are standing on their own. What I'm stumped on right now is how to deal with hot-spots and maybe lightmap contrast in general. There are sconces on walls and I use them as emissive textures to generate the lightmap bakes. In a typical Blender Cycles render, the surface nearest to the emissive sconce will get washed out. I bake the direct+indirect diffuse as a lightmap from this. When I apply this as the ambientTexture it looks close, but as I understand it, ambient is really a shadowmap, so its not making anything brighter than it already is and therefore no hotspots. I tried using lightmapTexture, but I don't think I understand how to format it correctly because setting my lightmap to it as-is effectively blasts on-top of everything rather than mix with it. The only thing that has come close to doing what I intend is applying the lightmap to the emissiveTexture and bumping up emissive color to BABYLON.Color3(5,5,5); It's rough, but it does get me surfaces that are lighter and darker than the albedo at the same time. (see bottom image for that) So that's where I'm at. I'm holding out hope that there's a proper way to mix lightmapTexture and albedoTexture that I'm just missing. Also open to alternative approaches if I happen to be running against the grain in what I'm attempting. Thanks in advance for any pointers. Blender Cycles preview render in Babylon with PBR Material albedoTexture = wrapping basecolor textures emissiveTexture = lightmap emissiveColor (1,1,1) albedoTexture = wrapping basecolor textures lightmapTexture = lightmap albedoTexture = wrapping basecolor textures emissiveTexture = lightmap emissiveColor (5,5,5)

I just did some experimentation with my own camera rig attached to a cannon.js physics object. Forcing the angular velocity every frame kind-of worked, but it leaks and doesn't absolutely stop rotation. What absolutely stopped rotation for me is calling this. ( just once, not on update ) object.physicsImpostor.executeNativeFunction(function (world, body) { body.fixedRotation = true; body.updateMassProperties(); }); So, its simple enough in cannon. I don't see an equivalent in Oimo yet.

Well thank you, that helped me troubleshoot things initially. It turns out adapting the player rig collision to a physics plugin wasn't the way to go. It more or less did what I wanted in terms of sticking to platforms, but raised all sorts of problems with basic motion. Manually applying the platform's velocity to the player rig while being stood upon or leapt from turned out to be much simpler. And now I'm off to write jump pads!

Hey guys, first post, started using Babylon Friday, so I may be a little green. I'm done waiting for Unity3D's webgl porting to not be a steaming pile. Really liking everything so far, but I could use some advice on moving forward with an FPS camera. I extended it from the BABYLON.FreeCamera. Nailed down most of it, but realized that the built-in collision the camera uses has no real concept of friction. It's going to be a bit of a problem when I intended on having moving floor platforms. They just slide right out from under you as-is. I'd rather not start from scratch or fall back on TargetCamera because of all the input groundwork that FreeCamera provides. My best guess for moving forward is to dig in and start overriding the collision functions of FreeCamera like _collideWithWorld(), _updatePosition(), etc. and replace them with Oimo compatible logic. I just want to get the problem out there before I go down that rabbit hole. Is this a horrible idea? Or maybe I'm just missing something incredibly obvious about the built-in physics? Thanks in advance for any advice.