Don't go through the floor

Hi,
I’m actually quite happy with my camera setup.
I can turn the camera and I can zoom.
But how do I keep the camera from going through the floor.

I parented the camera to another object and Rigid Body the other object (and the ground).
Just parenting it made the camera unusable, I couldn’t move anything.

Then I searched for angle restrictions and unfortunately found nothing.

I hope that someone here can help me.

Blender Scene (Sorry, New User, I’m not allowed to upload anything here)

Many greetings
Hans

ArmorySDK-2022-10
Blender 3.3
Win 10

Hi, maybe this thread can help you: How to avoid camera going through rigid bodies?. I’m not sure whether the examples from that thread still work in newer Armory versions, but the principle is the same. There are also some tutorials on Armory player controllers on Youtube, perhaps they also include camera collision but I’m not sure about that.

Hi timodriaan,

thank you very much for your answer.

Unfortunately, the “NoWallHit_nodes” crashes always with me.
But even if it would run, I wouldn’t know how to install it, because in my case the only object that moves is the camera.

What about limiting rotation, do you have any tips for me there?
(I have already searched the forum without success).

There’s got to be a simple solution to my little problem somewhere.

Many greetings
Hans

But even if it would run, I wouldn’t know how to install it, because in my case the only object that moves is the camera.

The principle is still the same, you basically need to do a raycast from the focus point of the camera to the camera (or to be more precise: the position where the camera should be if possible) and if it hits something along the way, you move the camera to that hit point instead. If the ray doesn’t hit anything, the camera is moved back to the position it should normally be (you could define this with a parented empty for example).

What about limiting rotation, do you have any tips for me there?

I think there are multiple approaches, but I would go with the following one:

You don’t directly control the rotation, but instead you control a variable that holds the amount of rotation. This variable is then clamped to the interval [0, 1] using the Math node’s Clamp option, and only the final clamped value is used to actually control the rotation.
For this you can use the Rotation Math node with the Lerp (Linear Interpolation) mode that can be used to mix two rotations with a factor. This approach is used in this example, but you will need to replace the “Math” nodes in the file with new ones since the automatic update seems to fail. Also, you can probably remove the “Init” part of the node and simply initialize the variables for both axes to 0.5 in the side bar.

This is how it would look like (original node tree from QuantumCoderQC’s example linked above):

If you only need to limit the rotation on one axis, simply remove the logic nodes corresponding to that axis and remove the “Combine (multiply)” node on the right side of the tree. It could also make sense to connect the “Out” output of the Set Variable node to the Set Object Rotation node instead of another On Update to ensure the correct order of operations within one frame. Otherwise there could be a 1-frame delay.

Another approach is shown in this video starting at minute 4.

I hope it helps :slight_smile:

1 Like

Hi timodriaan,

thank you very much for your tips.

Unfortunately I can’t combine your suggestions with my current camera, either I have limited rotation or I can turn the camera and I can zoom. (Please take a look at the blend in the first post)
It’s pretty frustrating that you can’t get anywhere for days even for the simplest things.
Slowly but surely, I’m losing my taste for Armory.

Again, thank you for your help
Hans

Hi, I could try to create a small example for your situation. But it will probably be based on what @ timodriaan mentioned above.

The main issue in your case is that you also have panning along with rotation. So you cannot simply limit rotation based on angle. If you pan higher up, you have more freedom to rotate. But if you pan down close to the floor, you should not be able to rotate below at all so as to not go through the floor.

While it might seem simple, it might actually not be…especially because of rotation, panning and zooming involved together.

P.S. the panning in your current blend file is not accurate once you rotate the camera. So that also needs fixing :grinning:

1 Like

Hi QuantumCoderQC,

“I could try to create a small example for your situation”
That would be really fantastic!

What I don’t understand…
Armory is a Gameengine for Blender, so why aren’t the Blender commands actually used.
Referring to my example:
I need 3 Constraints
Track to
Limit rotation
Limit location
Done. Took maybe 15 seconds.

Thank you very much and many greetings
Hans

“P.S. the panning in your current blend file is not accurate once you rotate the camera.”
The panning was actually not planned at all, I have then considered it as a nice addition.
Due to the lack of good documentation I use the trial & error method and am already satisfied if anything works at all.

Armory is game engine for Blender. However, simply put, Armory only supports these programming languages currently (ignore the mention of logic nodes, which use Haxe):

https://github.com/rpaladin/armory3d-vs-upbge#armory3d--upbge

image

In the past, Armory did support Python, but no longer does.

Long story short, this is due to the fact that back in the day, Armory was a fork of Blender, which allowed easy source tweaks, as well as accessibility to Blender’s API and Python modules. Since Armory is no longer a fork, but rather a Blender add-on, it can be fully and officially integrated into Blender, hence a true Blender Game Engine, unlike game engines that claim to be fully integrated into Blender like UPBGE. Unfortunately, though, it also means Python support, both natively as well, as well as Blender’s BPY API, are no longer supported.

In the long term, keeping up with Blender’s constant API changes is also a nightmare. UPBGE has that very issue, which is why they don’t release many updates, just bug fixes and Blender source updates.

Hi rpaladin,
thanks for the hint.

The lack of Tutorials and Demoscenes for HTML Export and the interactive Navigation in the scene also makes me feel like I’m the only one using Armory for something like this.
Anyway, I have to think of something else now so that I can finally get ahead.

  1. Armory uses the HTML5 exporter for all of the online demos listed at the Armory website. All of the blends are publicly available for download if you’d like to take a look at how they’re setup.

  2. Have you checked the official manual on HTML5 exporting?
    https://github.com/armory3d/armory/wiki/html5

  3. There are also these good tutorials.

By the way, is your original thread question about your rigid body following through the floor solved?

Hi rpaladin,

again, thanks for the links, but I already know them all.

By the way, is your original thread question about your rigid body following through the floor solved?
The Camera goes through the floor, not a rigid body.
No, I haven’t done anything like that in a few days either.
As I said before, basically only 3 simple things are missing.
Track to
Limit rotation
Limit location
Done in Blender in 15 seconds.

That can’t be right though. A camera has no physical properties, so it cannot be swayed by physics. Is your camera perhaps parented to another object, your player?

If so, does your player have a rigid body physic type set to type Passive? If your player’s rigid body settings were set to Active it would make it fall through the ground.

Hi rpaladin,

please read my first Post.

Hi, could you please share the blend file with the constraints applied. I know how to do it in Blender, but want to know how you configured the constraints.

Thanks

I hadn’t saved the scene at all.
Here again made very quickly.

Sorry, I forgot you posted a blend. To prevent the camera from viewing the bottom of the floor, I’d suggest implementing a camera collision check.

Basically what this would do is check is, send a raycast from the camera, outwards from the front, to determine whether an object is in front of the camera, for instance the floor. If the raycast returns true, that an object is in front of the camera, have either camera fov zoom-in, or transform the camera. I don’t suggest using last suggestion as much though.

Hi rpaladin,

thanks for the tips and the tutorial but there I do not get through.
As I had already written here, I can’t combine the different things.

I’m gonna put the whole thing on hold now.
I’ve already invested way too much time in it and endured too much frustration.

Thanks again for your help.