ProjectV Development Thread
- Thread starter Deleted member 3815
- Start date
- Sep 4, 2017
- 965
- 950
you mentioned an editor, is this some in game thing or a godot custom editor thing? if the second, would love to see it.
lobotomist
It is an "in-game" (more "in-menu-overlay") editor as part of the game not a separate custom editor thing for Godot.
For now it is not visually very fancy, typical programer art and UI spread over multiple debug menus with context filtered dropdown lists and preview images of game assets to choose and combine from or to add new stuff to the game at runtime.
It is an "in-game" (more "in-menu-overlay") editor as part of the game not a separate custom editor thing for Godot.
For now it is not visually very fancy, typical programer art and UI spread over multiple debug menus with context filtered dropdown lists and preview images of game assets to choose and combine from or to add new stuff to the game at runtime.
Added/Reworked camera system with additional true-firstperson camera and thirdperson camera
Added optional vehicles with both driver and passengers support
Some more open areas became to large for walking speed (beach, mountains). Extended all beach scenes beyond coastline and connected all island places with a "driveable" water surface.
Here is a demo video.
Added optional vehicles with both driver and passengers support
Some more open areas became to large for walking speed (beach, mountains). Extended all beach scenes beyond coastline and connected all island places with a "driveable" water surface.
Here is a demo video.
Last edited:
Some time ago I mentioned that character skeletons and therefor animations will get a huge rework so their wasn't much new on the animation front for a long time. Old character skeletons had many issues, especially with newer physics bones but also general with clipping and bending of 3D models and keeping all the moving parts together.
There is only so much you can hide in a 360° 3D animation compared to a still image render so every animation takes a long time to make. On top I have a strong aversion against misaligned models and airhumping in animations so it takes even longer.
Gladly this also improved a lot with the new character rigs as they are not only a lot easier to animate and share among characters but also have a lot of technical helpers in place to align multiple characters and all their bodyparts automatically together. For now only a few characters received the new treatment so still many to go.
WIP, only downscaled gif has a slow framerate, game has animations at smooth 60 fps
There is only so much you can hide in a 360° 3D animation compared to a still image render so every animation takes a long time to make. On top I have a strong aversion against misaligned models and airhumping in animations so it takes even longer.
Gladly this also improved a lot with the new character rigs as they are not only a lot easier to animate and share among characters but also have a lot of technical helpers in place to align multiple characters and all their bodyparts automatically together. For now only a few characters received the new treatment so still many to go.
WIP, only downscaled gif has a slow framerate, game has animations at smooth 60 fps
Last edited:
- Sep 4, 2017
- 965
- 950
Hand and feet bones have (better) Inverse Kinematic helper chains to keep them on floor and other surfaces. They also have follow bones so they keep sticking to a moving surface automatically. Bodyopenings have focusbones that activate additional inverse kinematic by proximity, e.g. each entrance has one enter bone and one ending bone. With a toggle everything that comes close first bends towards enter bone and if a certain distance inside automaticall bends further towards ending bone. e.g. from the front as seen in the gif clip a penis never clips in the pelvis mesh cause it first aims at the vagina bone and later at the cervix bone without additional keyframe editing but the same setup is used for wrapped around mouth, back, feet and hands and very flexible.
- Sep 4, 2017
- 965
- 950
2 questions:
1.- these follow bones you speak of, are they what's commonly refered as effectors and/or IK targets?
2.- Can you clarify how you achieve this IK by proximity?? is that like with colliders? I'm curious as how you switch from enter to ending bones.
1.- these follow bones you speak of, are they what's commonly refered as effectors and/or IK targets?
2.- Can you clarify how you achieve this IK by proximity?? is that like with colliders? I'm curious as how you switch from enter to ending bones.
1.) I don't know if this is the technical accurate term but follow bones are bones that serve no deform purpose inside the skeleton. Their only purpose is to serve as a animation targets for another bone (also from other skeletons), e.g. to copy location, transform or rotations. An IK Target is just one use of that, but it can be used for anything that needs to react to movement of another object/bone. I use Blender and Blender has many kinds of "BoneConstraints" that can be mixed together to achieve this.
2.) No colliders, just a property Driver that activates/deactivates multiple IK chains together per distance. They are only active while in reach of the IK target and the IK chain lower in hierarchy always aligns itself first.
2.) No colliders, just a property Driver that activates/deactivates multiple IK chains together per distance. They are only active while in reach of the IK target and the IK chain lower in hierarchy always aligns itself first.
- Sep 4, 2017
- 965
- 950
:S wait so the constraints are not for godot? I tought you were working on some in game IK system 
Anyways I didn't knew property drivers could do that, I should give them A try.
Anyways I didn't knew property drivers could do that, I should give them A try.
In theory it is possible to recreate such constraints through scripts in Godot but for everything that isn't hands or feet no, it is not feasable. It would be way to performance costly to have everything at runtime in Godot so it is baked in the animations. What runs in Godot is IK for final feet and hand placement with e.g. environment objects, and that alone already cuts performance in half for nebulous engine reasons.
I have to add that "baked in animations" doesn't mean things don't adapt/change at runtime in the game. Different animations and poses are blended together same as with the head lookat where no bone is changed through code but multiple pose assets are blended together to move a characters head in the right direction.
I have to add that "baked in animations" doesn't mean things don't adapt/change at runtime in the game. Different animations and poses are blended together same as with the head lookat where no bone is changed through code but multiple pose assets are blended together to move a characters head in the right direction.
Last edited:
- Nov 24, 2017
- 179
- 421
I wonder why do you use Godot for developing a 3D game when UE4 and Unity exist. It has a worse renderer, less features and its asset store is nothing in comparison. Sure things might change with 4.0 but seeing how stretched out their delays are I wouldn't be surprised to see it's release in 2022.
Last edited:
- Jan 26, 2021
- 99
- 319
i can tell you that you wont be (much) faster in UE4 or Unity, i'm almost 2 years working fulltime on my project in UE4 and i would guess that this project is developing at the same pace.
The asset stores might look neat in the first place, but often you spent more time fixing assets than you would spend on making your own, smix8 apparently realized that with DAZ content already. And so it's the same for UE4 marketplace, e.g.: they put a repeating seamless pattern in a 4k texture, which could be 64x64px, meshs with unnecessary high vertex count, complex material/shader setups which are their all purpose material, ... sure there are assets which are gold, but you only know once you bought them, or when someone sane reviewed them before.
Anyways, don't want to hijack this thread with further ranting, good work OP, what you showed so far looks promising to end up in an enjoyable game.
- Sep 4, 2017
- 965
- 950
I can say that it was the right decision to go with Godot.
I only considered Unreal Engine as a real contender, Unity was never an option for me (too many bad impressions on all ends). By now I have the knowledge to be productive with Unreal Engine and Python/C++. This wasn't the case for months when I first started this project. Godot has no liabilities for me and renderer performance is more than enough for what I need and it gets considerably better with each update.
I would have never reached the same level of long-term productivity with Unreal/Unity as a solo developer. Feature assets from an asset store are overvalued, it doesn't save time at all if you have to integrate them in a complex project. 3D store assets don't care much about the engine. I am using Unreal/Unity/DAZ assets in Godot just fine for testing. The load and build times on more complex/large games are so atrocious in both Unreal and Unity while it only takes seconds in Godot.
Yes you can buy a head-start with assets stores and the larger tutorial base for Unity and Unreal but developing systems in Godot myself had so much more value in the long run for both the project and myself as a (programming) person.
I only considered Unreal Engine as a real contender, Unity was never an option for me (too many bad impressions on all ends). By now I have the knowledge to be productive with Unreal Engine and Python/C++. This wasn't the case for months when I first started this project. Godot has no liabilities for me and renderer performance is more than enough for what I need and it gets considerably better with each update.
I would have never reached the same level of long-term productivity with Unreal/Unity as a solo developer. Feature assets from an asset store are overvalued, it doesn't save time at all if you have to integrate them in a complex project. 3D store assets don't care much about the engine. I am using Unreal/Unity/DAZ assets in Godot just fine for testing. The load and build times on more complex/large games are so atrocious in both Unreal and Unity while it only takes seconds in Godot.
Yes you can buy a head-start with assets stores and the larger tutorial base for Unity and Unreal but developing systems in Godot myself had so much more value in the long run for both the project and myself as a (programming) person.
I lacked the time. Primarly cause I started a new job that required a lot of time to setup.
Last edited: