Rigs of Rods

tdev wrote:

yes, i removed the feature that fixed this limitation since it was quite a slowdown for the beam algorithm. We need to find another solution i guess.

What about using omöy the 3 cmaera nodes as center for the cam ? WOuld be an easy fix and makes sense too imo.

I've been getting really bad FPS since you removed the camera patch whenever I hit something and parts detach. It was better before.

Can't you just allow truck authors to define certain nodes that the camera should ignore?

tdev wrote:

tdev wrote:

i added a patch that does what lifter proposed, BUT the camera feels different now :-

please test my attached patch if possible

Instead of just using the three camera nodes, what if you made it average based on the eight cinecam nodes? Both stable, but the cinecam ones might give a better feel.

tdev wrote:

gabester wrote:

Instead of just using the three camera nodes, what if you made it average based on the eight cinecam nodes? Both stable, but the cinecam ones might give a better feel.

good idea, i will test this soon :)

Any progress on this? Every vehicle I'm making has easily detachable parts, and it sucks having to repair/reinitialize every time one falls off because of the camera bug.

How's the progress on this? I like gabester's idea of the eight node binding instead of the three node.

Best option IMO would be to simply allow users to define a few nodes which are the center, otherwise default to the current camera method. That way it won't mess up already-released vehicles.

I think I get what you're saying. If it can basically act like you're in first-person camera view were the camera doesn't shake when parts detach. That would be good.

the problem is not the alignment of the camera.

the problem is the collision detection of trucks. If a truck is splattered all over a map, it will have always-on collision.
thats not acceptable...

thats a downside of RoR is that you can splatter vehicles.

Provoiding i interpreted you correctly,

I think a defined zone around the vehicle where detatchable parts become largely ignored should be implemented. Like RoR will only simulate a neerby vehicle if you're within a certian range of it and its not moving anywhere, kind of like a radius around your truck that allows nodes to be simulated. A so called 'simulation zone' I guess. Shouldnt we have it so that we can define certian nodes on a truck with detatchable parts to do the same as those trucks and not affect the placement of the radius wherein things are simualted around the truck? So detatchable parts arent always going to have collision on, or even be simulated all the time provoiding your far enough away from them. even when lost pieces are close to another truck thats parked(one your not driving). That should lighten the load on the processor. I hope I conveyed that correctly.

heck, you can even get the 'simulation zone' to be refferenced the same way the camera might be in the future, rather than an average of all nodes the truck is made from. With beamV2 its hardly common to make your vehicle splatter under normal driving circumstances anyway so we only need to worry about detatchable parts, Wich can be defined by the creator to be ignored outside of a distance from the vehicle. I hope I made sense to someone, maybe someone can word it better.

I dont know how RoR works with simulating things only when your close to them, Im only drawing logical conclusions from oservation.

i.e. make the detached parts go to sleep? Sounds like a plan to me.

Uhmm what does a .patch file do and how do i open them?

thecoolmeister wrote:

Uhmm what does a .patch file do and how do i open them?

please do us a favor and stay away from redmine. thanks

tdev wrote:

the problem is within truck <--> truck collision its based on bounding boxes (http://en.wikipedia.org/wiki/Minimum_bounding_box). Means: node with a certain radius of another truck -> check for collisions. If that node is some kilometers away the bounding box will be huge, dragging down FPS significantly.

then the same nodes excluded from the camera calculation due to their distance should also be excluded from all collision calculation

right, thats what I was trying to convey. certian detatchable nodes that are left out the calcualtion on the camera's placement should be left out of the calculation involving the binding box. Now i know what its called i shouldnt ever need to use the term "simulation zone" again. and to further aid the performance it should cease to be simulated once it has stopped bouncing around and gone outside of the binding box. like other objects do. It would be quite nice to destroy a car and see performance inprove a little rather than what happens now, where performane plummets.

Kadzait wrote:

right, thats what I was trying to convey. certian detatchable nodes that are left out the calcualtion on the camera's placement should be left out of the calculation involving the binding box. Now i know what its called i shouldnt ever need to use the term "simulation zone" again. and to further aid the performance it should cease to be simulated once it has stopped bouncing around and gone outside of the binding box. like other objects do. It would be quite nice to destroy a car and see performance inprove a little rather than what happens now, where performane plummets.

problem is that the bounding box increases and decreases in size and thats perfectly normal and expected behavior, take any mobile crane, the bounding box at span is significantly smaller than the bounding box when fully deployed.

There was a suggestion made to use the camera nodes to calculate camera position, and that sounded like a good intermediate approach until the bounding box issue could be taken care of. this is on my todo list once I'm done with fixing the patch for issue #50, which I'm close to.

How was the patch that was originally put in there working? Maybe there is some way of making it a bit simpler,also what revision was the patch implemented into the source because I've spent the last 10 minutes looking for it but can't find it....

I have a patch for this will post tomorrow, and it fixes old vehicles by using the average of the cinecam nodes, will post patch some times this week.

Nice Aperion, I'm sure everyone will be overjoyed.

Aperion wrote:

Kadzait wrote:

right, thats what I was trying to convey. certian detatchable nodes that are left out the calcualtion on the camera's placement should be left out of the calculation involving the binding box. Now i know what its called i shouldnt ever need to use the term "simulation zone" again. and to further aid the performance it should cease to be simulated once it has stopped bouncing around and gone outside of the binding box. like other objects do. It would be quite nice to destroy a car and see performance inprove a little rather than what happens now, where performane plummets.

problem is that the bounding box increases and decreases in size and thats perfectly normal and expected behavior, take any mobile crane, the bounding box at span is significantly smaller than the bounding box when fully deployed.

There was a suggestion made to use the camera nodes to calculate camera position, and that sounded like a good intermediate approach until the bounding box issue could be taken care of. this is on my todo list once I'm done with fixing the patch for issue #50, which I'm close to.

well, doesnt excluding cartian nodes from the calculation of the binding box's location also exclude them from effecting it's size?

just commenting to raise up this issue: http://thomasfischer.biz/?p=279

tdev wrote:

just commenting to raise up this issue: http://thomasfischer.biz/?p=279

Except I'm using map and not a vector. Which now that I think about it would be worse performance because of the look up times... hmm will have a look again, the main reason I used std::map was to avoid duplicate checking. Fortunately the code is written in such a way that it should be easy to replace. Thanks for looking at this Thomas, and thanks for the feedback!