7 réponses à ce sujet

[rjshae]

TheOneBlackRider wrote...

rjshae wrote...

Solved it, I think. Through the process of elimination I narrowed it down to the guard rails. After I lowered them a bit the problem went away.

It must be doing a line-of-sight calculation: the first part of the guard rails has the steepest rise and that is where the camera changed. Once the character moved forward up, he was high enough for it to revert back.

Thanks.

Would it be possible to post some screens (eg. before and after) with pointing out on the altered mesh(es), what exactly was done (eg. via arrows) or how to adjust "it", so that the "zoom in" is avoided?

Thanks.

Sure. I've included an illustration below.



In A, moving the PC onto the base of the ramp (outlined in magenta) causes the camera tilt seen in B. What I discovered is that the height of the left part of the side mesh (outlined in yellow) causes the problem.

Lowering the top part of the side face in C (blue arrows) to a certain point on the body, as in D, removed the problem. I'm not sure if the critical height varies with different creature sizes.

Here is a copy of the files I used to reproduce the effect:

https://www.dropbox....era_problem.zip

Modifié par rjshae, 29 novembre 2013 - 05:36 .

[Morbane]

funny thing - the first thing i think of is "graph paper" and how useful it was in p&p

[TheOneBlackRider]

Thanks for your time to create this and the shared files!
I only had the time for a quick import and did not test it IG. But could it be right, that lowering the C2/C3 mesh fixes it (which you did in your corrected model), not lowering the wall mesh?
I hope, that I'll find the time to check that with the mentioned RWS-suspenion bridge (which does this short camera close in) in the near furture. I'll report.

[rjshae]

When I experimented with that bridge model, I never changed the C2/C3 mesh so I don't think that's it. What I did find though is that scaling the ramp placeable in the X direction down to 0.9 or up to 1.2 makes the problem go away. Likewise, increasing the Z axis scale to 1.2 also fixes the problem. Wierd, huh? Thus it may only need some minor tweaking of the dirensions.

Morbane wrote...

funny thing - the first thing i think of is "graph paper" and how useful it was in p&p

Yeah, guess I was trying to get a sense of the scale. Probably more than was necessary.

Modifié par rjshae, 30 novembre 2013 - 01:04 .

[TheOneBlackRider]

Hm... I imported both your models next to each other (into Gmax) and the z of C2/C3 (test2-model) is a bit lower. Since C2/C3 are supposed to handle the camera, maybe that did the job. Maybe you scaled it town together with the other mesh(es)?
Again, I didn't find the time to check IG, if just lowering the C2/C3 on the original model would do the job.
But it's great, that you seem to have nailed down the solution, rjshae.

[rjshae]

That'd be good to know then. Thanks!

[TheOneBlackRider]

Finally found some time to test:
First: I couldn't reproduce the zoom in with your test models, rjshae: All was fine - going on and off, camera from back and front.
BUT lowering (just) the C2/C3 fixed the issue with that above mentioned suspension bridge. The zoom in only happened, when walking off the bridge and the camera beeing behind the toon.

So, lowering C2/C3 might solve this issue. I also tested it with a human toon. So, as rjshae wrote before, it needs to be tested, if this also works for smaller toons (halflings).

[rjshae]

I've got a large model I'm building that appears to demonstrate the camera issue can be caused by the model RIGD packets alone, rather than the C2/C3. The model consists of two towers with an empty gap in between that leads up to a ramp in gateway. As soon as the character steps between the two towers, the camera gets skewed around. Lowering the C2/C3/W down to almost ground level didn't eliminate the problem.

I think I'm going to have to separate out the tower and gate models. Oh well...

Modifié par rjshae, 24 décembre 2013 - 04:19 .