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.
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.
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.
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
“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
Done. Took maybe 15 seconds.
Thank you very much and many greetings
“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.
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.
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.
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.
Done in Blender in 15 seconds.
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.