The Star Citizen Thread v5

Status
Thread Closed: Not open for further replies.

ianw

I
Wobble vision 1.0 was replaced by Vision stabilisation 2.0.

At some point they may replace T pose 1.0 as well - who knows?
 

Esvandiary

Esvandiary
CIG really are some sort of awful hybrid of Apple and a certain presidential candidate sometimes... Everything they do is New and Unique and Never Before Seen, even when it's just removing something they added a year or so ago. Admittedly sometimes the "New and Unique" stuff comes from the fans rather than CIG itself though.
Either way, they can get away with it because (some of!*) their supporters will happily believe whatever they're told - even when it flat out contradicts what CIG said/promised before - and loudly shout down any criticism.

Stability improvements indeed. Personally I'm very much hoping some actual "stability improvements" come to the game - the networking especially - in 3.0...


* I always feel like I need to add this caveat because people like Mr.Nowak have a much more restrained view of the project, and can see its current flaws and problems while still being optimistic about its future. That I have no problem with at all.
 
Last edited:

Toumal

Toumal
To be fair, that does look a LOT better. You know, on-par with other shooters. And that is good. Not revolutionary as CIG may claim, but good.
 

ianw

I
Esvandiary said:
CIG really are some sort of awful hybrid of Apple and a certain presidential candidate sometimes... Everything they do is New and Unique and Never Before Seen, even when it's just removing something they added a year or so ago. Admittedly sometimes the "New and Unique" stuff comes from the fans rather than CIG itself though.
Either way, they can get away with it because (some of!*) their supporters will happily believe whatever they're told - even when it flat out contradicts what CIG said/promised before - and loudly shout down any criticism.

Stability improvements indeed. Personally I'm very much hoping some actual "stability improvements" come to the game - the networking especially - in 3.0...


* I always feel like I need to add this caveat because people like Mr.Nowak have a much more restrained view of the project, and can see its current flaws and problems while still being optimistic about its future. That I have no problem with at all.
Click to expand...

Presumably there is a backlash from all the hardocre supporters that originally supported wobble vision and shouted down any opposition - are they now petitioning RSI/CIG for a reinstatement?
 

Zyll Goliat

Zyll Goliat
Toumal said:
To be fair, that does look a LOT better. You know, on-par with other shooters. And that is good. Not revolutionary as CIG may claim, but good.
Click to expand...

I agree.....the thing is that CIG could do the very same thing ages ago if they didn´t loose time with head bobbing approach....but that´s the past now....credit is given where credit is due....something changed for better and we should appreciated that...
 

dsmart

Banned
D
JohnMice said:
What metrics? The same used to predict the 90 days collapse of a company or the one used to predict the closing of the Austin studio?
Click to expand...

Aside from the fact that you guys have nothing to offer by way of any tangible argument, so you keep regurgitating the same tired old FLAWED argument, it's easy to see how you would quote a few words from an entire paragraph in order to skew the context. So I will quote the whole thing again.

Not relevant.

According to metrics; the people still giving them money are pre-existing backers (some of who are whales) as reflected in the funding numbers (which we still thing is mostly ) compared to the number of backers.

Just because a number of backers are still giving them money by buying stuff, doesn't mean that the "noise" is any less relevant.
Click to expand...

And those metrics are right THERE on the funding page as well as the Google Sheets tracker page. I don't know about you, but I live and breath math; so numbers don't befuddle my brain. Aside from the fact that someone even has charts - lots and lots of charts (which we generate and pour over regularly) illustrating the funding metrics as it pertains to the number of backers & citizens.

Your turn. Make it good; I'm counting on you.
 

dsmart

Banned
D
Ben Parry said:
Admittedly that's a first-person model in the gif. If you look again (slowly, I guess?) you'll see that the animations it's playing would seriously screw up a third-person model. If anything, the common behaviour is to use separate models and animations everywhere.
Click to expand...

We were discussing this on our Discord channel yesterday. As I was on mobile, I didn't have the page to send you the origin of that GIF. But as I pointed out (as has Tippis who picked up on this chat from Discord), it doesn't illustrate what you think it does. As there is NO third person animation, that hacked 3rd person view shows what would happen in their absence. It doesn't show what happens if you have disparity between 1st and 3rd person animations.

My version of your analogy is a little different. I'm the guy installing the breaker box. If the guy installing the breaker box needs to know what brand of lightbulbs was used on each floor, then the wiring system was pretty badly designed. Maybe he has personal knowledge or opinions on lightbulb brands used generally in the industry, but assuming he needs to know that is weird.
Click to expand...

Yeah, that makes sense. However, given your expertise, comparing your skills and inserting them into your analogy, makes you the guy who wired the building; not the guy installing the breaker box. So if the guy installing the breaker box finds out that one of the breakers isn't hooked up, then you're the one responsible for that - not him.

To go back to the character example, the renderer ought to be able to handle any model in any pose. For sane maintainability, it shouldn't need to know whether that's a first or third person model, whether there would be a different animation in third person, whether the pose is a result of physics ragdoll, canned animation, or some mixture of the two, or even the animator's birthday.
Click to expand...

Agreed. But again, it's about context. As engine developers, our job is to ensure that the renderer - which is responsible for all the visuals displayed on screen - does it's job in all facets (level, character, animations, lighting etc). So in the course of that, you can't just assume "everything will be fine" if you abstract out the input. To put it another way, the animation system relies on the renderer. And during the course of developing the renderer you have to know what the animations look like when renderered. There is just no getting around that. It's no different from looking at a model that's lit incorrectly; then asking the modeler to take a look at the model itself in case there are improper vertices or similar issues.

And yes, the renderer doesn't need to know if the animation is in 1st or 3rd person. But it does need to know if it looks right visually. Which is why you saying that you only work on the renderer and have no clue about animations and such was puzzling to me.

Just: What model do you want, what materials does it display, where do you want it, how is it posed. (if you want motion blur, maybe some info about how that stuff was set last frame)
This is the exact opposite of too many cooks spoiling the broth, it's getting some of your cooks away from the broth to make starter and dessert based on a pre-agreed meal plan.
Click to expand...

As indies, we don't tend to have the benefit of 10 people working on an engine, whereby each person is focused on one aspect of it. An all hands on deck approach means that the guy responsible for the renderer, usually looks into everything that's visually on screen and ensures that it all looks right.
 
Last edited:

dsmart

Banned
D
CMDR_Orlando said:
Wrong

But don't take my word for it, just listen to actual game developers that actually worked on it @30:30

https://www.youtube.com/watch?v=WvlnG45Kois&index=20

The great majority of the games use different sets of animations for the handling the stuff in 1st POV.
Besides Arma or maybe other military sim's I don't recall other games that go that extra mile.

What you see in first person is not what your characther is actually doing, you can easily test this by watching the shadow's of the players that don't match what they are doing or even how the hands are positioned don't translate into how the shadow is casted, this because what you see one thing, what your characther is actually doing is other = Separated Animations.



Wrong. Both Battlefield 1 and the "new" COD are the most recent "state of the art" FPS's and they don't have 1st person and 3rd person integration. They do the same old like allways, have different animations for the arms. It has nothing to do with visual fidelity, it's all about how hard it is to make the animations fealing right from both views and the different needs of different games.

https://www.youtube.com/watch?v=Gl5oIIarMxs
Click to expand...

Everything you posted above, is rubbish. And the "evidence" you posted, doesn't support the argument you're trying to obfuscate.
 

Ben Parry

Ben Parry
dsmart said:
Yeah, that makes sense. However, given your expertise, comparing your skills and inserting them into your analogy, makes you the guy who wired the building; not the guy installing the breaker box. So if the guy installing the breaker box finds out that one of the breakers isn't hooked up, then you're the one responsible for that - not him.
Click to expand...
Neither way round really models the relationship very well.

dsmart said:
Agreed. But again, it's about context. As engine developers, our job is to ensure that the renderer - which is responsible for all the visuals displayed on screen - does it's job in all facets (level, character, animations, lighting etc). So in the course of that, you can't just assume "everything will be fine" if you abstract out the input. To put it another way, the animation system relies on the renderer. And during the course of developing the renderer you have to know what the animations look like when renderered. There is just no getting around that. It's no different from looking at a model that's lit incorrectly; then asking the modeler to take a look at the model itself in case there are improper vertices or similar issues.
Click to expand...
Key difference is subtlety. You look at a model where the normals have been exported wrong, it can take time at my end to pin down exactly why it doesn't look right and bounce it back to the right team. Send a model through with all the limbs in weird positions, the bug doesn't even land on my desk because it's intuitively obvious that the problem is a mis-posed model.
dsmart said:
As indies, we don't tend to have the benefit of 10 people working on an engine, whereby each person is focused on one aspect of it. An all hands on deck approach means that the guy responsible for the renderer, usually looks into everything that's visually on screen and ensures that it all looks right.
Click to expand...
And as non-indies, there's enough work to keep a guy busy without fishing around in other people's areas, so we benefit from creating clear boundaries of responsibility at interfaces, the ability for a system to vet whether incoming data are correct, etc. Different strokes, basically.
 

dsmart

Banned
D
CMDR_Orlando said:
What high resolution arms for holding weapons?
http://i.imgur.com/YemIS5O.jpg
Click to expand...

OK I'll bite; since you clearly have no clue what you're talking about. Let me try and break this down into the simplest possible forms for the layman.

When we - as devs - talk about "animations", we're not just talking about one type or sub-set. Here is a list of the more common ones:

1. weapons (reload, holstering, firing kickback etc)
2. character poses (run, walk, jump, pickup, idle etc)
3. items (e.g. drone deployment & pickup etc)

As far as weapons go, some of them tend to ALWAYS be 1st person only. e.g. if you have an ammo reload animation in 1st person and third person; what you see in 1st person, is totally different from what you see in 3rd person (either from a 3rd person camera, or in multiplayer, what another player sees you doing. However, things like firing kickback may only be in 1st person because it has no relevance in a 3rd person view unless you want another player to see the weapon kickback/shuddering for "fidelity" reasons.

Character poses do not tend to have a 1st person component. Why? well, it's simple. If you are crawling along the ground, how exactly are you going to depict that? You're not. So if you are prone and crawling, the 1st person view is a camera (e.g. lowered pov height) change, while the 3rd person animation is of the character crawling along the ground. If the game does not have a 3rd person camera, or multiplayer, then there is no need to have a prone crawl animation, as nobody is going to see it.

When you reload a weapon in 1st person, you see what the weapon is doing. If you are playing a game that has you picking up or deploying items, you also need animations for those. Again, if the game doesn't have a 3rd person camera, or remote viewing (multiplayer), then you don't need a 3rd person animation.

The disparity and problem these systems present can be broken down into:

1. animations which are only needed seen/required in 1st person, don't - and shouldn't have - 3rd person versions

2. if you use the same set of animations for both 1st and 3rd person, the number of problems increase exponentially depending on the type of game. e.g. a weapon reload animation which looks great in 3rd person, may look completely incorrect in 1st person, even if you put the camera in a bone tethered to the head of the character model.

3. similar to the above, a character holding a weapon in 3rd person, will look great there; but in 1st person - even with camera manipulation - will look completely wrong. in fact, even if you don't mess with the camera attached to the bone, the pov alone will ensure that you see anomalies such as the camera intersecting the model, the weapon is off screen, the weapon is too low etc. you can get around some of these with cheats e.g. instead of leaving the camera attached to a bone in the head (where it should be), you can move that camera dynamically (or at load time) forward etc, until the pov looks better.

Here is an example. This is a series of shots from the test (I don't quite like it btw, but it's useful as a POC) 3D cockpit in LOD. When the character model is in the 3D cockpit, the camera tethered to the bone in the head (where it should be) gives a horrid pov of the cockpit. This was even after that camera was setup in the editor prior to export. And the fact that we have 8 unique character models, doesn't help. So we had to dynamically move the camera (attached to the bone) when the character is in the cockpit, in order to have a better pov that shows the cockpit elements (e.g. the MFDs contain live data). If we didn't have the character in the 3D cockpit model, it won't make any difference since we can put the camera wherever we like. Except that the character hands need to be holding the joystick.

I don't know how they are doing it in Star Citizen, but going back to what I know about CryEngine, if SC is using the same animation for 1st and 3rd person view, the fact that the weapon view looks perfect now, indicates to me that they are in fact manipulating the pov camera as there is no other way for them to achieve that unrealistic 1st person pov. What do I mean by this? Well I have firearms training; and I can tell you with absolute certainty that when you are holding a pistol in real life, your pov is NOT what you see depicted in a game. Especially given the fact that factors such as weapon type, human arm, human height etc, all play a roll in that pov.

And again - if they are using the same set for 1st and 3rd, that would explain why they couldn't remove the head bobbing all this time; because if it's part of the character animation (walk, run etc), there is NO way to change it without redoing the animation, removing those frames, and re-exporting the model etc. And they may not have done that all this time because they were looking to move to mocap data anyway. As for mocap data, again, it has no relevance to 1st person, since it's just movement animations.

Why do most games which require 1st and 3rd person have different sets of animations? Read everything I posted above. But here are some other reasons:

In the 1st person view, the player's pov is so close that a low quality model and texture, will appear pixelated. So the solution is to have things like hands and the weapon at the highest quality possible. That high quality is NOT required in the base animation (used in 3rd person camera and remote viewing) because it becomes a performance issue. Imagine creating a 100K polygon character just because you want to use it in both 1st and 3rd person due to the arms (which will be seen in 1st person) needing to be high quality. Well guess what happens in a multiplayer game when you have 16 people, all with 100K polygon models, weapons etc jammed into an already high detail scene. Chug (which btw is one of the primary reasons that Star Citizen performance sucks. Somewhere along the line they completely forgot about any of this - or didn't care).

Even things like weapons can be a problem; which is why back in the day, the 1st person weapon had a higher visual quality than the one used/seen in 3rd person. Nowadays, the performance loss is immaterial, so you can easily use the same HQ weapon for both 1st and 3rd cameras. Even so, a level of detail setting (if available) can control the quality of the one used in 3rd person for some performance gains.

Which brings me to your pointless jab (I love those because they allow me to show some people how ignorant of facts/issues they are) above....

When I designed LOD and started developing it in 2010, I already knew that the size of the game, and the sheer number of assets would result in a performance issue. That was even before we completed the engine. The content creation had to be started early. Then in 2011, I decided to ditch the home grown engine in the interest of time (and not reinventing the wheel), and license a slew of middleware to build a custom engine.

I wrote a series of blogs about this.

http://lodgame.com/15-10-27-state-of-play/
http://lodgame.com/15-09-04-state-of-play/
http://lodgame.com/15-07-31-state-of-play/

By the time the engine was at a point where performance could be gauged, analyzed etc, the game was already 100% content complete (that was back in 2013 btw).

The result is that we ended up with a powerful space and planetary engine, complete with infantry, air, ground, sea, space dynamics - but lower quality 3D assets which either didn't look all that great for a genre game, or didn't push the limits of the engine. NOTE that for all my previous games, I had built the engines (graphics, AI, animations etc) from scratch.

Earlier this year, we started evaluating which assets needed to be improved upon or completely redone. It's all right there in the game's roadmap (LOL!! yeah, we have that) btw.

So we started with the character arms, weapons, aircraft, vehicles - assets which needed improvement. Later the content creators will move to scene elements (buildings etc) and get those improved upon as well.

Since we use different animations for 1st person and 3rd person, the arms used in the 1st person animations (weapons etc), needed to be redone at a higher quality; as did the weapons.

aircraft:

URL]

weapon + arm:

URL]
URL]

weapon (older):

URL]

3rd person crouch and swim animations; not present in 1st person

URL]

URL]

URL]

URL]

While you don't get to see the arm in all instances, due to the type of weapon and/or character, they are in fact of much higher quality than the actual arms on the character model used in the 3rd person camera. Again, this was done for performance reasons due to the sheer number of players who could be in the same place at the same time.

The game's media page actually has shots going all the way to 2011.

That also goes for the game's art style. As I mentioned in the blogs above, I opted for a more colorful art style (in contrast to all the Greys in Star Citizen), and while some assets at low quality don't look good up front, with on-going revisions, they can be made to look better (we don't yet have the benefit of PBR in the engine) while still retaining the game's art style and performance. When you look at games with a colorful art style like Overwatch, Battleborn, Atlas Reactor, Team Fortress etc, the quality is in the models because the art assets don't benefit from much detail.

So yeah, that's what I'm talking about. Hopefully, instead of arguing and debating things you are clueless about, while engaging in attacks, that you take the time to actually learn something - even if it's coming from someone you don't like. There is no shame in that; only knowledge.
 
Last edited:
Status
Thread Closed: Not open for further replies.
Back
Top Bottom