elk

Sure. I made a quick demo;

https://cdn.soft8soft.com/AROAJSY2GOEHMOFUVPIOE:53632680b5/applications/test_first_person/test_first_person.html

Se the attached image for the setup in blender, I tried to mark the sections and options you need to look for.

The things you need to set up is as follows;

In the camera properties under Verge3D Settings, change the camera to First-Person.

Then make a new mesh object, model it to cover the areas you want to be able to move to, the green mesh in my demo.

Then you create a material that will be used only for this purpose, I just made it green to make it stand out, but it doesn’t really matter because we can hide the mesh object from being rendered in the exported scene anyway, just toggle of the camera icon for the mesh object.

Back in the camera settings again you need to select the collision material you just made in the Collision Material field.

Place your camera above the mesh, if not you will float a bit while moving until you are above the mesh and “snap” to it.

That is basically it, press “sneak peak” to check it out.

I set up the demo with a blue wall, as you can see there is a hole in the green mesh under the walls, and that is what is stopping you not the wall itself, I keep a bit of distance so the camera wont clip into the wall if you stand too close, but that depends on scene scale and camera settings so play around to find the way you like to set it up. Also i made a little second floor to demonstrate the “falling of” i mentioned, if you go to the edge with the first floor under you you see you get snapped down to the first floor, as I mentioned; hopefully they will get that implemented soon, but i already think this is a great camera mode, and so easy to set up really.

Of course you would put your objects around to get the visuals, the collison mesh is never meant to be seen. So no physics engine used, and if you did want to go that route you would also need an invisible collision mesh for that and that would also need the walls in it, not just the floor element like this setup.

A bit of a long post, but i hope this help you out.

Did not see your last post before I posted. Not sure if you could store it in a variable, my solution was to use the material to store it in a way, using a variable might be better if that would work, at least for some more complex scenarios.

All I did to keep from walking through walls was make a mesh with a dedicated “collision material” where i cut the mesh where there is supposed to be walls (see attached image) you can also make the mesh incline for stairs or hills, but you will be dropped downstairs if there is overlap once you pass the edge of the second floor. Once exported it will not render by default i think(or you might just need to disable the render button in the outliner for it), so you can tweak it to not follow the visible enviorment. But if you need avatars to not go through eachother and have more “physical” collisions you would have to do it with physics yeah. I just find the First Person camera so easy to work with for my need that I thought I would mention it. Good luck with your project

Have you had a look at the First Person Camera, search for it in the 2.10 release post;

Verge3D 2.10 for Blender/3ds Max Released

It is not based on the physics system, but you can set up a material that the camera controller will snap to making it a walkable surface, and you will not be able to go outside it, the one thing that is missing for my needs is that if you have multiple floors you will get snapped down to the first floor if you go of the edge of the second floor. The team has it in there TODO list, and hopefully it will make it in by the 2.12 release. Check out the City example in your applications folder to see a bit how it works. If you need it to behave more physical, like jumping or falling and stuff you might want to go for physics yeah. I have not sett that up for anything yet, but if its more of a ArchViz project you got, i think the first person camera is really nice. Someone else or the Verge3D will surely have some more insight on setting up physics if you need that. Hope this was helpful.

Just had a quick look at your puzzles, so i might be reading it wrong, but It looks to me like you are trying to assign the textures(or “state”?) and not the materials when you press the texture 1 and 2 buttons, so changing tex1 and tex2 in the two top puzzles “groups” with Tex1Diffuse and Tex2Diff in the assign material puzzles should help i think. Also it looks like you are updating both materials with the new texture when using the upload button, i guess you would want to separate that out to one event for each button. Hope that makes scense … if I´m thinking correctly here …

Hi Alexander. And thanks for quick reply

I know I could probably get it done with physics, but if possible i would really like to see this in the FPS camera. That would keep me from having to do a loot of tweaking of the physics parameters for one, and I would not have to add the extra overhead of doing “actual” physics computations (that would be important for mobile apps for instance), and i could keep my navigation meshes to a minimum. Introducing physics would also demand a bit of extra testing for every scene and scenario.

If I’m guessing your implementation on the FPS camera correctly, it might be as “simple” as exposing a value for how long the raycast is to check for the collision material. A checkbox for custom raylenght and a number for the lenght of the raycast might be a good solution for the interface. But ofcourse everything takes away a bit of time and resources to implement.

Looking forward to hearing your thoughts on this.