Please or Register to create posts and topics.

Naming Conventions

#1 · January 25, 2022, 1:29 am

Quote from 2DNED on January 25, 2022, 1:29 am
Blink boxes, occlusion, portals

Overall naming conventions:

CL01x - Collision for Ladder
CB01x - Collision for All
CA01x - Collision for Armory
CE01x - Collision for Emplaced weapons
CF01x - Activates special functions (ex: FARPs)
CT01x - Change team box
CP01x - Collision that only affects players (not AI)
CV01x - Allows objects to be triggered.
BBxx – Blink box
VCxx – Collision for vehicles
VKxx – Collision for vehicles kluge-flagged objects.
-----------------------------------------------------------------------

Blink boxes:

BBxx – Turn off everything: sky, voxels, water, objects, outside lighting.
BBWxx – Turn off everything except water.
BBSxx – Turn off everything except sky.
BBVxx – Turn off everything except voxels.
This convention can be grouped. For example, BBWSV01 will turn off everything except water, sky and voxels.
-------------------------------------------------------------------------
Occlusion:

OBxx - A closed volume which keeps geometry it obscures from being rendered. This is a simple form so it should only be used for solid geometry without holes.

OSxx – The occlusion “shell” of a building. This provides occlusion against other buildings by being a sort-of silhouette. (No other sub-object numbers should be used, hence shown here as OS01 and not OSxx)

OPxx-xx – A one-sided plane that nulls the occlusion properties of a portion of the OS01. This is used as a portal to look into buildings. (The naming convention denotes the direction of the normals by listing first where it is coming from [02] and then where it is facing [01], in this example becoming OP02-01.)
----------------------------------------------------------------------------

Using occlusion and blink boxes with a building:

Blink boxes are usefull because they prevent the engine from rendering the entire 3d world when it would be unnecessary to do so. If a player is inside a room for example, with one door and no windows then it would be helpful to tell the engine not to draw the outside objects and terrain. That’s where blink boxes come in. Used efficiently they can improve the framerate.

The average NovaLogic map may have anywhere from fifty to a few hundred strips, including the terrain, water, and sky as well as all of the objects placed on the map. A building that uses occlusion and blink boxes may allow you to turn off the terrain and outside objects, providing a tremendous framerate savings. In some cases, separating a building interior into16 sub-objects with their 16 corresponding blink boxes (the maximum number of blink boxes that you can use in one .3di) will allow the engine to ignore as many as a few hundred outdoor strips.

And for very complicated structures that use a lot of polygons and/or materials it sometime helps the framerate if the structure is separated into multiple parts rather than one large 01 object. In that case you will want to use blink boxes. If a player is standing in a room labeled 02 for example, the engine can save rendering time by not drawing the exterior of the building (part 01), or adjacent rooms (parts 03 and 04). We use occlusion portals (flat invisible planes placed in doorways and windows) to help the engine know what parts of a structure are visible to the player and therefore need lo be rendered.
For buildings above ground you have the option of using blink boxes or not. However, for underground buildings, tunnels for example, you have no choice but to use blink boxes.
Blink boxes also allow interiors of buildings to be lit with indoor lighting (instead of the brighter sunlight or dim moonlight, depending on the time of day).
----------------------------------------------------------------------------

Using Blink Boxes

When modeling a building with multiple rooms the exterior of the structure is called part
01. And the interior part(s) arc 02, 03, etc.
For any structure you make that uses blink boxes and multiple parts, the Collision volumes are all considered to be part of the 01 object. In other words, your collision volumes would be named CB01 floor, CB01 wall, etc. even though the tub-objects are called 02 room, 03 room etc.

Tunnels are a little different and we'll skip them for now. But, we'll throw in the following brief explanation:
Underground objects including tunnels must use blink boxes. A simple tunnel object would be named 02. And it would have a BB02 blink volume. Bui it still requires a 01 object. This is because the code expects a 01 shell object. For tunnels, generally we make a single faced 01 object and assign it a nodraw material.
The same collision and blink box rules apply to tunnels.
Additionally we make entrances to tunnels that we describe as "men's room corridors" because the terrain must be switched off before the player sees the tunnel. But we won't cover that here.

Blink Box volumes have a few restrictions.
The same shape restrictions that apply lo collision volumes also apply to blink volumes - no concave shapes allowed.

The engine has a limit of 16 blink boxes per
3di. (meaning any combination of volumes, e.g.
BB02a, BB02b. BB03, BB04, etc. that adds up to 16 total BB volumes).

Generally speaking, blink boxes provide their maximum benefit when a building has fewer openings, such us doors, windows, or holes in the walls. Keep in mind that a building with say 10 rooms doesn't necessarily need to have 10 blink boxes, although it may be beneficial to separate the interior into that many sub-objects.

Blink boxes can overlap slightly but there should never be more than .5 meters between adjacent blink boxes. This is because the engine draws a detection sphere around the player that extends a half meter beyond the player's center point (the sphere is one meter in diameter). So, if an artist places adjacent blink boxes farther apart than .5 meters then the player will momentarily see one sub-object disappear from view when he walks from one blink box to the other.

The distance between a blink box and the outside of your object should be at least .5 meters. As mentioned above, the player has a detection sphere with a radius of .5 meters. And a portion of the player's detection sphere can extend through walls, ceilings and floors, including their collision volumes, to a depth of up to .5 meters. So, for example, if a player is standing outside a building and the player's sphere inadvertently touches a blink box inside the building then outdoor objects will disappear from view. This is a possibility when the player is standing outside o building wall, or prone on a rooftop. It's also a possibility if the player climbs some objects inside a blink box so that he is prone near the ceiling (something to keep in mind when setting the height of your blink box as well as your ceiling collision).

The solution is to always insure that there is more than ,5m between the edges of your blink box and any outside walls. And special attention also needs to be paid to ceilings and upper room floors. Keep in mind that map designers may decide to stack objects inside a blink-boxed room, potentially allowing a player to climb up to the ceiling.
-------------------------------------------------------

Occlusion Shell Notes:

Buildings that use blink boxes for the interior must also have
an OS01 ("Occlusion Shell 01). An Occlusion Shell is similar lo
an Occlusion Box (e.g. OB01) in thai they both mask out other
objects.
But an Occlusion Shell is different from an Occlusion Box in that the OS allows for openings such as windows and doors. When the engine encounters a building with an Occlusion Shell the engine knows that it must then check for OP planes (Occlusion Portals), and the engine will occlude everything except what is visible through the OP planes.
--------------------------------------------------
Occlusion Volume Restrictions:

Occlusion volumes have the same shape restrictions as Collision volumes. Occlusion volumes must be convex as opposed to concave (in theory a sphere should work, but a torus shape will not). In practice though, the code can be a little finicky and the simpler the shape the better. Rectangular volumes and parallelogram shapes lend lo work well. Occlusion volumes (both OB and OS) can be costly if there is more than one per object. Generally speaking, you should try to limit a building to one OB/OS object or maybe two if the building is L-shaped (e.g. OB01a, OB01b).
Because they mask out background objects, the artist needs to be careful about the size of the Occlusion volume. An Occlusion volume that extends beyond ils house object, for example, will cause objects to noticeably disappear when they should be visible. The OB and OS volumes should always be completely enveloped by the building's geometry. And the artist should be mindful ofthe effects that the various levels of detail will have. In other words, if a portion of a building will be missing from the low res version of a model than that portion should not have an occlusion volume.
----------------------------------------------------------

Occlusion Portals:

Occlusion Portals help the engine determine which part of an object to render. An object with nn Occlusion Shell and Blink Box must have at least one Occlusion Portal.

Occlusion Portal Restrictions:
Occlusion Portals must be planar (all vertices must be on the same plane).
Occlusion Portals should roughly conform to the shape of an opening in the actual geometry. A rectangular doorway should have a simple, reclangulnr Occlusion Portal. Out a perfectly round corridor opening could be approximated with, say, an 8-sided Occlusion Portal. There's nothing magical about the number 16 in regards to Occlusion Portals. But, generally speaking, since the complexity of an Occlusion Portal is one of the factors that affects framerate the artist should use the simplest OP that roughly matches the shape of a doorway.

Occlusion Portals don't have to be limited to doorways. A large room, for example, could be cut in half with one large Occlusion Portal plane between the two room halves, making each half a separate sub-object.
Occlusion Portals should be no further away from their Blink Box than .5 meters for the reason described above (see restrictions for Blink Boxes)
Naming Convention: In 3D Studio Max® the normals of an Occlusion Portal always face FROM the first part number TOWARDS the second part number. For example: OP04-02 Occlusion Portal with its normals facing from part 04 to part 02.
The direction you choose to face the normals is arbitrary, but you'll need to follow the naming convention above. Therefore, an Occlusion Portal named OP02-04 would be identical to the portal named above except that in this case its normals arc reversed.
-------------------------------------------------------------------------------

All Credits to EE and LOA for the write up

Blink boxes, occlusion, portals

Overall naming conventions:

CL01x - Collision for Ladder
CB01x - Collision for All
CA01x - Collision for Armory
CE01x - Collision for Emplaced weapons
CF01x - Activates special functions (ex: FARPs)
CT01x - Change team box
CP01x - Collision that only affects players (not AI)
CV01x - Allows objects to be triggered.
BBxx – Blink box
VCxx – Collision for vehicles
VKxx – Collision for vehicles kluge-flagged objects.
-----------------------------------------------------------------------

Blink boxes:

BBxx – Turn off everything: sky, voxels, water, objects, outside lighting.
BBWxx – Turn off everything except water.
BBSxx – Turn off everything except sky.
BBVxx – Turn off everything except voxels.
This convention can be grouped. For example, BBWSV01 will turn off everything except water, sky and voxels.
-------------------------------------------------------------------------
Occlusion:

OBxx - A closed volume which keeps geometry it obscures from being rendered. This is a simple form so it should only be used for solid geometry without holes.

OSxx – The occlusion “shell” of a building. This provides occlusion against other buildings by being a sort-of silhouette. (No other sub-object numbers should be used, hence shown here as OS01 and not OSxx)

OPxx-xx – A one-sided plane that nulls the occlusion properties of a portion of the OS01. This is used as a portal to look into buildings. (The naming convention denotes the direction of the normals by listing first where it is coming from [02] and then where it is facing [01], in this example becoming OP02-01.)
----------------------------------------------------------------------------

Using occlusion and blink boxes with a building:

Blink boxes are usefull because they prevent the engine from rendering the entire 3d world when it would be unnecessary to do so. If a player is inside a room for example, with one door and no windows then it would be helpful to tell the engine not to draw the outside objects and terrain. That’s where blink boxes come in. Used efficiently they can improve the framerate.

The average NovaLogic map may have anywhere from fifty to a few hundred strips, including the terrain, water, and sky as well as all of the objects placed on the map. A building that uses occlusion and blink boxes may allow you to turn off the terrain and outside objects, providing a tremendous framerate savings. In some cases, separating a building interior into16 sub-objects with their 16 corresponding blink boxes (the maximum number of blink boxes that you can use in one .3di) will allow the engine to ignore as many as a few hundred outdoor strips.

And for very complicated structures that use a lot of polygons and/or materials it sometime helps the framerate if the structure is separated into multiple parts rather than one large 01 object. In that case you will want to use blink boxes. If a player is standing in a room labeled 02 for example, the engine can save rendering time by not drawing the exterior of the building (part 01), or adjacent rooms (parts 03 and 04). We use occlusion portals (flat invisible planes placed in doorways and windows) to help the engine know what parts of a structure are visible to the player and therefore need lo be rendered.
For buildings above ground you have the option of using blink boxes or not. However, for underground buildings, tunnels for example, you have no choice but to use blink boxes.
Blink boxes also allow interiors of buildings to be lit with indoor lighting (instead of the brighter sunlight or dim moonlight, depending on the time of day).
----------------------------------------------------------------------------

Using Blink Boxes

When modeling a building with multiple rooms the exterior of the structure is called part
01. And the interior part(s) arc 02, 03, etc.
For any structure you make that uses blink boxes and multiple parts, the Collision volumes are all considered to be part of the 01 object. In other words, your collision volumes would be named CB01 floor, CB01 wall, etc. even though the tub-objects are called 02 room, 03 room etc.

Tunnels are a little different and we'll skip them for now. But, we'll throw in the following brief explanation:
Underground objects including tunnels must use blink boxes. A simple tunnel object would be named 02. And it would have a BB02 blink volume. Bui it still requires a 01 object. This is because the code expects a 01 shell object. For tunnels, generally we make a single faced 01 object and assign it a nodraw material.
The same collision and blink box rules apply to tunnels.
Additionally we make entrances to tunnels that we describe as "men's room corridors" because the terrain must be switched off before the player sees the tunnel. But we won't cover that here.

Blink Box volumes have a few restrictions.
The same shape restrictions that apply lo collision volumes also apply to blink volumes - no concave shapes allowed.

The engine has a limit of 16 blink boxes per
3di. (meaning any combination of volumes, e.g.
BB02a, BB02b. BB03, BB04, etc. that adds up to 16 total BB volumes).

Generally speaking, blink boxes provide their maximum benefit when a building has fewer openings, such us doors, windows, or holes in the walls. Keep in mind that a building with say 10 rooms doesn't necessarily need to have 10 blink boxes, although it may be beneficial to separate the interior into that many sub-objects.

Blink boxes can overlap slightly but there should never be more than .5 meters between adjacent blink boxes. This is because the engine draws a detection sphere around the player that extends a half meter beyond the player's center point (the sphere is one meter in diameter). So, if an artist places adjacent blink boxes farther apart than .5 meters then the player will momentarily see one sub-object disappear from view when he walks from one blink box to the other.

The distance between a blink box and the outside of your object should be at least .5 meters. As mentioned above, the player has a detection sphere with a radius of .5 meters. And a portion of the player's detection sphere can extend through walls, ceilings and floors, including their collision volumes, to a depth of up to .5 meters. So, for example, if a player is standing outside a building and the player's sphere inadvertently touches a blink box inside the building then outdoor objects will disappear from view. This is a possibility when the player is standing outside o building wall, or prone on a rooftop. It's also a possibility if the player climbs some objects inside a blink box so that he is prone near the ceiling (something to keep in mind when setting the height of your blink box as well as your ceiling collision).

The solution is to always insure that there is more than ,5m between the edges of your blink box and any outside walls. And special attention also needs to be paid to ceilings and upper room floors. Keep in mind that map designers may decide to stack objects inside a blink-boxed room, potentially allowing a player to climb up to the ceiling.
-------------------------------------------------------

Occlusion Shell Notes:

Buildings that use blink boxes for the interior must also have
an OS01 ("Occlusion Shell 01). An Occlusion Shell is similar lo
an Occlusion Box (e.g. OB01) in thai they both mask out other
objects.
But an Occlusion Shell is different from an Occlusion Box in that the OS allows for openings such as windows and doors. When the engine encounters a building with an Occlusion Shell the engine knows that it must then check for OP planes (Occlusion Portals), and the engine will occlude everything except what is visible through the OP planes.
--------------------------------------------------
Occlusion Volume Restrictions:

Occlusion volumes have the same shape restrictions as Collision volumes. Occlusion volumes must be convex as opposed to concave (in theory a sphere should work, but a torus shape will not). In practice though, the code can be a little finicky and the simpler the shape the better. Rectangular volumes and parallelogram shapes lend lo work well. Occlusion volumes (both OB and OS) can be costly if there is more than one per object. Generally speaking, you should try to limit a building to one OB/OS object or maybe two if the building is L-shaped (e.g. OB01a, OB01b).
Because they mask out background objects, the artist needs to be careful about the size of the Occlusion volume. An Occlusion volume that extends beyond ils house object, for example, will cause objects to noticeably disappear when they should be visible. The OB and OS volumes should always be completely enveloped by the building's geometry. And the artist should be mindful ofthe effects that the various levels of detail will have. In other words, if a portion of a building will be missing from the low res version of a model than that portion should not have an occlusion volume.
----------------------------------------------------------

Occlusion Portals:

Occlusion Portals help the engine determine which part of an object to render. An object with nn Occlusion Shell and Blink Box must have at least one Occlusion Portal.

Occlusion Portal Restrictions:
Occlusion Portals must be planar (all vertices must be on the same plane).
Occlusion Portals should roughly conform to the shape of an opening in the actual geometry. A rectangular doorway should have a simple, reclangulnr Occlusion Portal. Out a perfectly round corridor opening could be approximated with, say, an 8-sided Occlusion Portal. There's nothing magical about the number 16 in regards to Occlusion Portals. But, generally speaking, since the complexity of an Occlusion Portal is one of the factors that affects framerate the artist should use the simplest OP that roughly matches the shape of a doorway.

Occlusion Portals don't have to be limited to doorways. A large room, for example, could be cut in half with one large Occlusion Portal plane between the two room halves, making each half a separate sub-object.
Occlusion Portals should be no further away from their Blink Box than .5 meters for the reason described above (see restrictions for Blink Boxes)
Naming Convention: In 3D Studio Max® the normals of an Occlusion Portal always face FROM the first part number TOWARDS the second part number. For example: OP04-02 Occlusion Portal with its normals facing from part 04 to part 02.
The direction you choose to face the normals is arbitrary, but you'll need to follow the naming convention above. Therefore, an Occlusion Portal named OP02-04 would be identical to the portal named above except that in this case its normals arc reversed.
-------------------------------------------------------------------------------

All Credits to EE and LOA for the write up

franekma has reacted to this post.

Forum

Naming Conventions

Recent forum posts