A convincing floor texture does not make a floor solid. Collision is a separate part of the asset, and an opening in the visible model can still be blocked by collision from your resource or the surrounding world.
For this exercise, return to the original two-room workshop. Keep the visible shell unchanged while validating movement.
Define the collision job
Decide which surfaces must block movement and which openings must remain usable. Write a short route: approach the entrance, cross the front room, enter the workshop, walk its perimeter, and return outside.
Use simple collision geometry that preserves the meaningful shape of the space. Decorative grooves and small trim usually do not need the same complexity as the visible mesh. This is a modeling choice to evaluate against the intended interaction, not a numeric polygon rule.
The Sollumz interior collision guide describes the collision composite workflow, material assignment and room-specific floor setup. Use its version-matched conventions for the exported structure and room IDs.
Inspect what the player will contact
View the collision independently from the visible shell. Check the floor plane, steps, walls, entrance and inner doorway. Look from below as well as from the normal player view. A floor that seems present from above may have a gap or an unexpected face orientation.
Temporarily simplify the visible scene while inspecting. You want to see whether the collision opening aligns with the doorway, not whether the doorway has attractive trim.
When modifying an existing location, identify overlapping vanilla or third-party collision before deleting anything. Removing the first visible blocker is not sufficient evidence that you found every relevant collision asset. Avoid broad replacements that affect nearby roads or buildings.
Test room-related floor setup separately
The documented workflow uses room-specific collision materials so room IDs can be set. Keep an explicit mapping in your project notes: which floor region belongs to which room, and how that is represented in your tool version.
Do not infer those values by adding one to a room list index. Inspect the actual data or documentation for the version you are using. Where the tool exposes generated room data, review it after changing the room layout.
If a behavior changes exactly at a boundary, test the same route again without changing portal connectivity. Isolating collision-related changes prevents a room setup problem from becoming a series of unrelated edits.
Walk the same route every time
Begin outside, away from the resource. Approach the entrance at normal walking speed and at a run. Cross the threshold at its center and near both edges. Repeat this at the internal doorway.
Walk along every wall, over any floor joins, and into corners. Test the stairs or changes of level you actually included. Depending on the space’s intended use, check other interactions separately rather than assuming that a successful walking test proves everything else.
Use screenshots or short recordings to identify exact failure points. “Blocked at the left entrance edge while moving north” is actionable. “Collision broken” is not.
Separate collision from visibility
A player falling through an otherwise visible floor suggests a different investigation from a room disappearing while the player remains supported. Do not fix the first symptom by changing textures or the second by thickening every floor.
Verify that the exported collision is the current version and is delivered with the same release as its matching archetype and placement data. Keep a clean resource folder; an old file with a familiar name can survive many exports if you only copy over changed files.
Finish by reconnecting and testing with neighboring resources enabled. Keep the same movement route so a new conflict is easy to compare with your isolated baseline.