5 replies to this topic

[lride]

I feel like it's better to separate the rendering geometry and physics geometry, but this takes up twice as much memory as using one same geometry for both rendering and physics.

[zacaj]

Usually you don't use high resolution graphical assets for the physics, you'd either use really low quality versions or primitive shapes (boxes, cylinders). Either way, you need to store two versions, and the physics one should take up much less space than the rendering version. Plus, that data really isn't that big, compared to even a single texture

[ATC]

Absolutely... And there should be, in my opinion, a complete separation from visual game entities and logical/physical game entities! For a physics object, for example, the visual representation should do nothing more than mirror the transformations of the logical representation. The logical representation holds the physics hull and all of the calculations are made against it, whereas the visual representation just follows it and gets rendered.

[Hodgman]

Also, your rendering geometry is generally stored in the GPU's RAM and has more attributes, like tex-coords, whereas your physics geometry is generally stored in regular CPU accessible RAM.

[superman3275]

I separate mine. How I do it is to have a separate Rendering Geometry and Physics Geometry. My Physics Geometry figures out what forces to apply to what (So I'll pass in Collision Points to physics along with some other general information like the type of collision) and then sends the forces to rendering, which will render the objects correctly.
Hodgman is correct too. Rendering concerns the GPU, while your Physics should be doing the calculations, so that's stored in the CPU's RAM, just like he said.

[MAD UNICORN GAMES]

It's better practace to seperate the two, it will provide the most advantages in the long run.