Adjusting an object's collision size to match rescaled object

[VonHelton]

Collision meshes can be a child to either their own independent root parented to a Root, or to the visible mesh, either will work. And do please remember to ALWAYS collapse any modifiers before exporting, specially XFORM ones. Make a duplicate of the whole scene so you don't lose anything.

 

Ok.....

 

1. What modifiers are you referring to?

2. Making a collision a child to its own root sounds like a plan. How do I do that without Nifskope yelling at me?

3. Maybe a better question would be what your 3ds Max settings are on imports & exports, settings for Nifskope, Outfit Studio & Elrich.

 

:thumbsup: :thumbsup: :thumbsup: :thumbsup:

[greekrage]

a) elrich has a settings folder ...Load settings from there..

B) in my example i obviously did the whole routine with proxies...( i didnt think i had to mention it......)

c) by collapsing modifiers we mean the modifiers that the object takes when you do the collision routine... Just go to each effected part you made collision for and its clone ,click each one and do... "reset Xform " and then collapse /collapse selected...etc for each part..

 

We dont use specific settings to export but we do use a specific plugin and thats the gamebryo...NOT the netmerse

 

Watch KingGath's 2 vids on collision to get the method in your head...

 

When i did yours ...all i did was follow the method to the letter...nothing else and you saw the result...

[RoNin1971]

I'm using Blender for the most part myself, but the principles remain the same.

 

Lets say I want to modify an existing mesh to something new (like I did a 1000 times at least by now)

 

First I import the/a nif to start with.

& Modify it.

In case I increased the poly count & applied modifiers (typically a displacement & decimate) I make a copy and convert it to a mesh (same result as 'collapse') & I apply ALL location, rotation & scale adjustments.

 

To make sure it all says 0 (no offset from X,Y,Z. always should be at 0,0,0)

NO scale, NO rotation.

 

Then I create my (to be) 'colision objects' using primitives. (box, plane, cone) (beware that for the collision object created in the end, it does NOT do inward bends, or holes. So a big round object with a round hole in the middle doesn't work!, The outside will be round, but the hole is ignored. Same with any arc. It will follow the outer arc, but create a straight line instead for the inner arcs. you need to use a bunch of box primitives to do that correctly.)

 

First I export my mesh to a nif (without the (to be) collision objects)

& then I export the collision meshes with 1 of the other objects to a nif.

 

In 3DS 2013 I import the (to be) collision meshes.

First I set the material. Create a new one, with the BSLightingFX... or something (can't look, I'm at work, on a break) add a texture for the Diffuse and apply that to the 1 object mesh. (anything goes. it doesn't matter as I'm not using the model)

 

Then select the primitive and create a rigid body, using the havok tools. A compound one if there's multiple primitives. This will turn them into a single collision object on export.

 

After that I assign the type. Mostly Metal or Metal hollow in my case & static. Apply that to all the primitives.

 

Then I export it to a new nif.

 

I put that nif into Elrich meshes folder and process it to turn it into a real collision.

 

Then I open my first 'object mesh' nif & the one from Elrich 'processed' folder.

& finally copy the collision (by parent node, as it always seems to put my collisions in a separate node)

to my object mesh, and be done with it. (as for the collisions anyway)

 

As for the materials, I just copy the right materials & textures using nifskope if needed.

 

When doing it all within 3DS you can skip some steps, but should probably be doing more work on the materials.

[VonHelton]

Ok, near as I can tell, "reset X-form" is a *REQUIREMENT* to doing collisions.

 

You take your object, reset X-form & then make a collision object by duplicating your primary object.

 

Then follow the rest of the instructions.

 

My bay windows now work perfectly.

 

And yes, make sure your object is set to 0, 0, 0.

 

In nifskope, move everything to your object.

 

DO NOT move your object in nifskope for any reason.

 

:thumbsup: :thumbsup: :thumbsup: :thumbsup: :thumbsup:

Edited February 2, 2023 by VonHelton

[pepperman35]

As mentioned before, duplication your primary object (i.e., a complex mesh object) for your collision object is not the best practice. The following is pulled from the Havok Content Tools manual.

3.2.1. Modeler vs. Simulation Shapes

The Havok Content Tools allow you to specify a shape type to be created from a given a mesh in a modeler. That means that, for the physical simulation, you generally use a different representation for the object to the actual representation in the modeler. For example, you can simulate a car chassis as a box, a head as sphere, or a forearm as a capsule. The advantage of this is that a simpler representation (box, sphere, cylinder) will be simulated faster than the original mesh models could be, with no noticeable changes on behavior. Another advantage is that it is more memory-efficient to represent these simple objects (e.g. a sphere is just a center and a radius) than it is to represent a whole mesh. Therefore, it is important to carefully select a shape type for each shape in your scene.

The following list presents the different kinds of Havok shapes, ordered by their complexity (simpler shapes will be simulated faster):

Sphere (simplest)

Capsule

Box

Convex Hull / Cylinder

Mesh (most complex)

Notice that this is only an indication. Complexity of the simulation also depends on many other variables - whether the object is fixed or not, whether objects are in contact or proximity, relative size, etc..

Shapes used by run-time rigid bodies can not change throughout a simulation. If an object whose geometry changes over time is used to define a shape in the modeler, then only its geometry at the initial export frame is used to define the exported shape.

Edited February 3, 2023 by pepperman35

[VonHelton]

 

As mentioned before, duplication your primary object (i.e., a complex mesh object) for your collision object is not the best practice. The following is pulled from the Havok Content Tools manual.

3.2.1. Modeler vs. Simulation Shapes

The Havok Content Tools allow you to specify a shape type to be created from a given a mesh in a modeler. That means that, for the physical simulation, you generally use a different representation for the object to the actual representation in the modeler. For example, you can simulate a car chassis as a box, a head as sphere, or a forearm as a capsule. The advantage of this is that a simpler representation (box, sphere, cylinder) will be simulated faster than the original mesh models could be, with no noticeable changes on behavior. Another advantage is that it is more memory-efficient to represent these simple objects (e.g. a sphere is just a center and a radius) than it is to represent a whole mesh. Therefore, it is important to carefully select a shape type for each shape in your scene.

The following list presents the different kinds of Havok shapes, ordered by their complexity (simpler shapes will be simulated faster):

Sphere (simplest)

Capsule

Box

Convex Hull / Cylinder

Mesh (most complex)

Notice that this is only an indication. Complexity of the simulation also depends on many other variables - whether the object is fixed or not, whether objects are in contact or proximity, relative size, etc..

Shapes used by run-time rigid bodies can not change throughout a simulation. If an object whose geometry changes over time is used to define a shape in the modeler, then only its geometry at the initial export frame is used to define the exported shape.

 

 

I totally get the idea of using simplified shapes as collision objects. The problem is when you get to objects like spiral stairs.

If I use a box as a collision, I won't be able to use the stairs at all.

I'll keep bumping into an invisible wall & so will the NPC's.

 

:cool: :cool: :cool: :cool: :cool:

[RoNin1971]

 

 

As mentioned before, duplication your primary object (i.e., a complex mesh object) for your collision object is not the best practice. The following is pulled from the Havok Content Tools manual.

3.2.1. Modeler vs. Simulation Shapes

The Havok Content Tools allow you to specify a shape type to be created from a given a mesh in a modeler. That means that, for the physical simulation, you generally use a different representation for the object to the actual representation in the modeler. For example, you can simulate a car chassis as a box, a head as sphere, or a forearm as a capsule. The advantage of this is that a simpler representation (box, sphere, cylinder) will be simulated faster than the original mesh models could be, with no noticeable changes on behavior. Another advantage is that it is more memory-efficient to represent these simple objects (e.g. a sphere is just a center and a radius) than it is to represent a whole mesh. Therefore, it is important to carefully select a shape type for each shape in your scene.

The following list presents the different kinds of Havok shapes, ordered by their complexity (simpler shapes will be simulated faster):

Sphere (simplest)

Capsule

Box

Convex Hull / Cylinder

Mesh (most complex)

Notice that this is only an indication. Complexity of the simulation also depends on many other variables - whether the object is fixed or not, whether objects are in contact or proximity, relative size, etc..

Shapes used by run-time rigid bodies can not change throughout a simulation. If an object whose geometry changes over time is used to define a shape in the modeler, then only its geometry at the initial export frame is used to define the exported shape.

 

 

I totally get the idea of using simplified shapes as collision objects. The problem is when you get to objects like spiral stairs.

If I use a box as a collision, I won't be able to use the stairs at all.

I'll keep bumping into an invisible wall & so will the NPC's.

 

:cool: :cool: :cool: :cool: :cool:

 

If your stairs has railings and those are 1 object, you will get a (inaccessible) 'box' anyway.

 

To do it correctly you should use a box for each step, and define a stairs with navmeshing.

Or use a ramp, which is what I usually do.

 

The complexity isn't really a big issue, as a convex hull is created which will encompas the mesh used to create the collision.

However, using primitives gives you greater control as to where the collision will be and where not.

[Ethreon]

Object origin should be centered, but the mesh itself doesn't have to.

[greekrage]

 

 

 

As mentioned before, duplication your primary object (i.e., a complex mesh object) for your collision object is not the best practice. The following is pulled from the Havok Content Tools manual.

3.2.1. Modeler vs. Simulation Shapes

The Havok Content Tools allow you to specify a shape type to be created from a given a mesh in a modeler. That means that, for the physical simulation, you generally use a different representation for the object to the actual representation in the modeler. For example, you can simulate a car chassis as a box, a head as sphere, or a forearm as a capsule. The advantage of this is that a simpler representation (box, sphere, cylinder) will be simulated faster than the original mesh models could be, with no noticeable changes on behavior. Another advantage is that it is more memory-efficient to represent these simple objects (e.g. a sphere is just a center and a radius) than it is to represent a whole mesh. Therefore, it is important to carefully select a shape type for each shape in your scene.

The following list presents the different kinds of Havok shapes, ordered by their complexity (simpler shapes will be simulated faster):

Sphere (simplest)

Capsule

Box

Convex Hull / Cylinder

Mesh (most complex)

Notice that this is only an indication. Complexity of the simulation also depends on many other variables - whether the object is fixed or not, whether objects are in contact or proximity, relative size, etc..

Shapes used by run-time rigid bodies can not change throughout a simulation. If an object whose geometry changes over time is used to define a shape in the modeler, then only its geometry at the initial export frame is used to define the exported shape.

 

 

I totally get the idea of using simplified shapes as collision objects. The problem is when you get to objects like spiral stairs.

If I use a box as a collision, I won't be able to use the stairs at all.

I'll keep bumping into an invisible wall & so will the NPC's.

 

:cool: :cool: :cool: :cool: :cool:

 

If your stairs has railings and those are 1 object, you will get a (inaccessible) 'box' anyway.

 

To do it correctly you should use a box for each step, and define a stairs with navmeshing.

Or use a ramp, which is what I usually do.

 

The complexity isn't really a big issue, as a convex hull is created which will encompas the mesh used to create the collision.

However, using primitives gives you greater control as to where the collision will be and where not.

 

Depends on the stairs like this for example... As you see the collision looks perfect (mesh).... but for some reason in game i cant walk up.... Scale is as the vanilla so where is the issue ?

[greekrage]

 

 

 

As mentioned before, duplication your primary object (i.e., a complex mesh object) for your collision object is not the best practice. The following is pulled from the Havok Content Tools manual.

3.2.1. Modeler vs. Simulation Shapes

The Havok Content Tools allow you to specify a shape type to be created from a given a mesh in a modeler. That means that, for the physical simulation, you generally use a different representation for the object to the actual representation in the modeler. For example, you can simulate a car chassis as a box, a head as sphere, or a forearm as a capsule. The advantage of this is that a simpler representation (box, sphere, cylinder) will be simulated faster than the original mesh models could be, with no noticeable changes on behavior. Another advantage is that it is more memory-efficient to represent these simple objects (e.g. a sphere is just a center and a radius) than it is to represent a whole mesh. Therefore, it is important to carefully select a shape type for each shape in your scene.

The following list presents the different kinds of Havok shapes, ordered by their complexity (simpler shapes will be simulated faster):

Sphere (simplest)

Capsule

Box

Convex Hull / Cylinder

Mesh (most complex)

Notice that this is only an indication. Complexity of the simulation also depends on many other variables - whether the object is fixed or not, whether objects are in contact or proximity, relative size, etc..

Shapes used by run-time rigid bodies can not change throughout a simulation. If an object whose geometry changes over time is used to define a shape in the modeler, then only its geometry at the initial export frame is used to define the exported shape.

 

 

I totally get the idea of using simplified shapes as collision objects. The problem is when you get to objects like spiral stairs.

If I use a box as a collision, I won't be able to use the stairs at all.

I'll keep bumping into an invisible wall & so will the NPC's.

 

:cool: :cool: :cool: :cool: :cool:

 

If your stairs has railings and those are 1 object, you will get a (inaccessible) 'box' anyway.

 

To do it correctly you should use a box for each step, and define a stairs with navmeshing.

Or use a ramp, which is what I usually do.

 

The complexity isn't really a big issue, as a convex hull is created which will encompas the mesh used to create the collision.

However, using primitives gives you greater control as to where the collision will be and where not.

 

Depends on the stairs like this for example... As you see the collision looks perfect (mesh).... but for some reason in game i cant walk up.... Scale is as the vanilla so where is the issue ?