True- its a bit mystifying why quick tests are not done to check these things.
Graphic Glitch in Crouch Walk
- Thread starter CMDR Darth Vater
- Start date
Hehe, can you imagine if you're the intern at FDev in charge of "crouch animations QA"?
The troubling aspect is all this can be done there and then and tested so easily- rig the character, add the new customisation and then swap to the parented camera in the characters head / and / or drop it into the engine and do a few poses.
I agree that in a perfect world it should always be like that. But you summarized it well, for this task you need : animation + 3D art (the different cosmetics) + QA + maybe dev. It's a lot of time and money. Really, it's a job for an intern.
What are you talking about?how about my 50 characters? (I'll be ok with even 20)
Idk what physics engine you're using but you coming with strange questions to me.
Animations themselves have nothing with number of chars using them.
After all, we are talking about 1st person animation which used in one instance - player.
3rd person may be a different animation branch.
Like I said the problem is on animation and models end, not on the engine part.
Animations were poorly tested. Models are not fixed. That's all.
Anyway, if you're know what physics engine was used in EDO and know how animations work for them - then why you still not fixed them but complaining how "hard" to fix them?
Looks like devs forgot to remove, idk, placeholders for attach points? So they're appear in some view angles in 1st person?
Last edited:
I have no idea about the pipeline, but its basic stuff that takes seconds to check. I used to use 3DS Max / Lightwave / Blender as a hobbyist and when I'd rig characters after building them its like one of the most basic things you do. Even a lone intern artist can do that, because all it involves is swapping cameras and checking. Even out of game engine you can see problems like this.
Right, we're not talking about the same thing. All I mean is that you're just talking about theory, from a pure animator perspective in their 3D software / workflow. I'm pointing the fact that shipping an acutal game (wich will contains many characters), with interactivity and dealing with programmers and other specialties is miles away from where you're at.
The thing I think the most underestimated in game dev is the back-and-forth between team members. QA is a job by itself, you cannot count on artists to do that reliably (you got paperwork and report to do). Also most of the time animation and 3D art are also made by different people. It's a nightmare to coordinate everything, especially when you're crunching.
Mate, looks like you still didn't see the problem. And started to talk about irrelevant things.
Nevermnd, I don't want to discuss anymore. It's pointless.
Yeah the discussion went the wrong direction. But trust me, your solution (2 animations) is inferior to mine (hiding renderer of the flashlight in 1st person view). It's ok to be wrong, but you're the one that started to talk like a pro while you're obviously a junior.
Last edited:
Facepalm.
That "renderer" is an animation bone, part of rig, with attached light.
It can be moved, it can be culled, it can be everything.
I wish to call everything as renderer too, and feel like a pro.
"If something drawable have issues - that's renderer". Too general.
Alright-alright, we already got you're a super-pro person.
Anyway, IT'S NOT a flashlight.
I put a screenshot of culprit some messages ago. That are some placeholder meshes, when flashlight is on different place and have a different shape.
So it more like not an animation problem, or engine problem, but just a leftover.
Last edited:
It's not the flashlight. It's the shoulder pad. If I swap the left shoulder pad out for a different one, it doesn't clip into my view when I'm crouching as badly. Same with the shoulder decals - on bare shoulders they still clip in but not as badly, but on shoulder pads they get right into your view. It also depends on which shoulder pad sets you're using - the raider left shoulder pad is at an angle so the decal isn't applied on a bit facing you directly, so it's less visible.
The fact that selecting "no decal" instead gives you a big orange smiley face is a separate bug.
The fact that selecting "no decal" instead gives you a big orange smiley face is a separate bug.
Its quite clear nobody here understands game development. What is needed is more fidelity. Just layer those fidels in and once the pipelines are in place everything will speed up.
The body you see from first person isn't what's being rendered for the 3rd person view. You can test this by watching your character's shadow, or the third person animations, or having someone else watch your character, and note how there are notable discrepancies.
The way to avoid these issues is to lock the viewport to the character model then carefully animate that model to move plausibly. This is what games like ARMA do, and they don't have the issues you see with EDO or CP2077 or quite a few other games, because the first person view is aligned with the eyeballs of the only model, not floating at an arbitrary position with the first person stuff (invisible from third person) tacked on. It's more work because things have to actually line up correctly, but it does prevent other problems, and means that what you see your character do and what others see your character do is always the same, lag not withstanding.
I'm not trying to win the technical argument with you. But to show that there are always several solutions to one problem, and that you're the kind of person who often gonna choose the worst one.Facepalm.
That "renderer" is an animation bone, part of rig, with attached light.
It can be moved, it can be culled, it can be everything.
I wish to call everything as renderer too, and feel like a pro.
"If something drawable have issues - that's renderer". Too general.
Alright-alright, we already got you're a super-pro person.
Anyway, IT'S NOT a flashlight.
I put a screenshot of culprit some messages ago. That are some placeholder meshes, when flashlight is on different place and have a different shape.
So it more like not an animation problem, or engine problem, but just a leftover.
The rule of thumb in game-dev is to choose the easiest / simplest / cheapest (in dev cost) solution. You just tunnel-vision about technicalities. Since you're a (junior) animator, you see everything from the animation perspective and forget that they're much more effective solutions using programming :
"some-stuff-to-hide.renderer.enable = false; // job done"
Meanwhile, what you propose is to create / maintain 2 animation files for this. Anybody who works in game would understand the cost of this, but somehow not you (that's how I know you're a junior / amateur).
It's all natural that you fall in those common pitfalls but if you want people to teach you, you have to talk to them better:
Lol, exactly my solution. It doesn't matter you label stuff to hide in your 3D software or in code, it's the exact same logic. And for sure it's more maintainable than your dumb idea of duplicating animation files.
Edit: Morbad afterward confirmed that there are indeed 2 animations (1st-person and 3rd-person). But I still think that your reasoning about using animation to hide stuff is probably dumb.
Last edited:
Why would they animate something that you're not supposed to see? It could be to draw accurate shadow of yourself in 1st-person view, but that sounds kind of overkill to me.
Edit : also not reliable since there's a growing number of cosmetics, some with huge elements. Good luck to "carefully animate" that.
Last edited:
This is what broke my nerves from the start. This mentality, you're an outsider from FDev and you come like "Haha, animators screwed up, once more" while it's just you who don't see the big picture. Not professional.
Last edited:
I made more thinking about this. I think that what might be happening is that FDev went @RetroPaladin dumb solution of "letting animator insure that nothing will obscure 1st-person view".
Then they realized later on that it will not work because of the crazy festive cosmetics. If you move an 'animation bone' 50cm away from the cam, how do you know 1 month later they'll not attach a 1m wide pumpkin on it?
Then they realized later on that it will not work because of the crazy festive cosmetics. If you move an 'animation bone' 50cm away from the cam, how do you know 1 month later they'll not attach a 1m wide pumpkin on it?
What aren't you supposed to see? This is a multiplayer game (which implies as many third person perspectives as you have additional people in the instance) as well as one with a third person camera, shadows, and potentially reflections. Cosmetics, which are also supposed to be visible to others, should have the same detail and care of integration as everything else, else they look sloppy.
Evidently, there is something about doing everything twice (world space and view space) that is easier than doing the world space to sufficient detail for a direct translation to eye space to look right. That doesn't mean it's desirable or doesn't have trade-offs.
Does make it simpler to have cosmetics that won't get in the way of the first person view, though it would be nice if cosmetics that cost a significant fraction of what the game does were integrated better.
My bad, I didn't explain it properly, because I got distracted by the other dude technical gibberish.
I
For 1st-person view anim:
When I say "why animate something you don't see", I meant they can selectively hide part of the body (like the stuff obscuring in 1st-view, is it a flashlight, shoulders or whatever, we don't care). You're correct when saying that they still cannot do that with "legs, arms" and everything that you can see in 1st-person.
My bottom-line is: Animation, which is the act of making a bone move, is not the best way to hide stuff. Tweaking a boolean is the optimal way. RetroPal keeps calling this "animation work" because they saw you can write string labels in their 3D software ('culling annotations for bones")
.Edit: "why not animate only the stuff you're supposed to see and 'boolean' hide the sub-parts you should never see"
Last edited: