Drawable Spans

[Sirius]

I often want to extract objects from a PRP to put them into another. Those who already tried it might know the hardest part: the visible part in the Drawable Spans (more than 150 lines only for 1 face).
Everything else can be extracted with PageEditor or PRPShop (well, as long as you don't mind spending hours on PRCC next ).
Of course, you can import the meshes into Blender and re-export them but you usually lose some infos, or can't import the scene at all.

I could extract some objects thanks to Chacal's great help, for example:

Extraction.jpg (315.76 KiB) Viewed 5229 times

(I always wanted to merge Myst V Ages with Uru's)

Currently I know how DrawableSpans mainly work but there are still some things I would like to know, that's why I ask here if anyone knows about these things. Please help me.

• Icicles:
  I don't know how these things work:
  - SubType next to Material
  - Everything in MatrixInfo
  - BoneIndices
  - Dists
  There is also VertexSpan: you can use the buffer infos in Icicle (just below it) as PyPRP does. But with Cyan these are never the sames. And what are GroupIdx, CellIdx and CellOffset ?
• ParticleSpans:
  I never saw this one used.
• SpanSourceIndices:
  The default syntax is this one for each Icicle:
  <SourceIndex type="0x00000000" value="0" />
  (value is incremented each time.)
  Are there other options ?
• FogEnvironments:
  Default is NULL="True". Other possibilities ?
• SourceSpans:
  I never saw anything here.
• SpaceTree:
  This one is quite complicated. It looks like it is used to parent objects (and then it would explain why I could never parent the Kadish sparkly to its pillar. I might be wrong however).
  
  • <SpaceTreeParams Root="38" NumLeaves="20" />
    Here I guess NumLeaves is the number of objects in this "tree". However in this case it was used for every objects in the file. I don't know about "Root". Maybe an object out of the Drawable Spans. Inside it you can find the next two categories:
  • <plSpaceTreeNode Flags="0x0001" Parent="24" LeafIndex="0">
    This category is used for each object. I don't think Parent can be the Parent icicle as there were only 20 icicles in this case. If there is no parent object, the value is -1.
    LeafIndex is the icicle number.
    Inside this paragraph there are only 3D coordinates (for parenting maybe).
  • <plSpaceTreeNode Flags="0x0000" Parent="38" LeftChild="34" RightChild="35">
    Here I don't have any clue. Parent, Left and Right child are above the icicle number
• I know approximately how to use the other categories.

Any help would be greatly appreciated .

[diafero]

Space tree is an optimization technology. The "parenthood" in there has nothing to do with the logical object parenting (to make objects move with each other). It is basically a binomial tree separating the 3d world space by ever smaller bounding boxes, each one being contained in the parent one. The nodes of the tree are the visible objects. If a scene is drawn, each object is checked for being in the visible volume - thanks to them being organized in a tree, the amount of checks only grows logarithmic with the number of objects in the scene.
The code in PlasmaClient that uses the space tree was very helpful for me understanding what's happening.

[Paradox]

• VertexSpans:
  Plasma has a hierarchy of span types. The first (plSpan) just contains some general flags and information about the span, but none of the actual data.
  The vertex span has extra fields that refer to vertex data. The vertex data is stored in buffer groups, which contain buffer cells, which contain encoded vertex information (someone should back me up on this, I've never looked too deeply into the vertcoder stuff).
  
• Icicles:
  The next type of span is an Icicle. I don't know what it stands for, but it's basically a triangle mesh.
  
• ParticleSpans:
  These are "placeholders" for particle systems. Each particle is actually a plane with a texture applied, the engine will dynamically create those planes and store them in these spans.
  
• SpanSourceIndices:
  I believe this is partly used when building the DSpans at export time. See the SourceSpans explanation below.
  
• FogEnvironments:
  The allows you to set the fog colour and density on a per-span basis. It is never used, but it works (if you hack things together with PRC).
  
• SourceSpans:
  When Cyan exports a DSpan object, they build a temporary GeometrySpan for each object, and then compress them all into the Icicles and vertex data. During export, this stores those temporary GeometrySpans. It should always be empty if you're looking in the final exported PRP files.
  
• SpaceTree:
  Diafero explained the basics here fairly well. It's not a parenting relationship, but a bunch of "nested boxes". At the lowest level of the tree (the leaves) are the bounding boxes for each of the Icicles.
  The SpaceTree makes it fast to do things like dynamic lighting. If a ray of light doesn't pass through a box, then it doesn't pass through any of the children either. You can eliminate calculations for half your scene very quickly.

Some interesting history for those who care:

Show Spoiler

Plasma originally supported two types of drawables: triangle meshes (ice), and patches. These were stored in two different classes, plDrawableIce and plDrawableMesh (or plDrawablePatchSet?)
At some point, it was decided that all drawables should be stored in the same class, with the spans differentiating between the types. That is when plDrawableSpans was born.
PotS still supports patches, although they are never used and I haven't been able to find any useful information. The patch spans are a subclass of plVertexSpan but don't include all the same information as a plIcicle.
MOUL removed/disabled support for patches (with a comment that they hadn't been used in years), and Hex Isle completely stripped them from the DrawableSpan file format.

You might be interested in looking at branan's AgeCreator project. He was (at one point) working on splitting DSpans back into GeometrySpans for each object, and then recompressing them when it was saved. This should give you a way to export a single object, and import it somewhere else.

[Sirius]

Thank you !!! These are really interesting infos.
So: for the Icicles, should I care about the "VertexSpans" line or the "Icicle" line ?

Do you have an example for FogEnvironments ?

The code in PlasmaClient that uses the space tree was very helpful for me understanding what's happening.

I guess I should take a look to it. It sounds interesting.

You might be interested in looking at branan's AgeCreator project. He was (at one point) working on splitting DSpans back into GeometrySpans for each object, and then recompressing them when it was saved. This should give you a way to export a single object, and import it somewhere else.

So, that would be a quick way to extract objects ? It should be easier.

[Paradox]

Do you have an example for FogEnvironments ?

Code: Select all

<?xml version="1.0" encoding="utf-8"?>

<plFogEnvironment>
   <plKey Name="prinFog" Type="plFogEnvironment" Location="189;3" LocFlag="0x0000" />
   <FogParams Type="None" Start="0" End="0" Density="0" />
   <Color>
      <hsColorRGBA red="0.5" green="0.5" blue="0.5" alpha="0" />
   </Color>
</plFogEnvironment>

I used that to change the fog in the nexus area of Ahra Pahts. It was part of an automated Makefile, which you might also find useful/interesting:

Code: Select all

Prin: Pahts_District_Prin.prp
   PrpPack -x Pahts_District_Prin.prp
   for d in `ls ./Pahts_Prin_PRP/ | grep "004C" | sed 's/\[004C\]/.\/Pahts_Prin_PRP\/\[004C\]/'`; do \
       echo "$$d"; \
       prcdc -v pots -o "$$d.prc" "$$d"; \
       sed '/FogEnvironments/,/\/FogEnvironments/ s/NULL="True"/Name="prinFog" Type="plFogEnvironment" Location="189;3" LocFlag="0x0000"/' -i "$$d.prc"; \
       rm -f "$$d"; \
       prcc -v pots -o "$$d" "$$d.prc"; \
       rm -f "$$d.prc"; \
   done;
   for f in ./PrinPRC/*.prc; do \
       echo "$$f"; \
       prcc -v pots -o "`echo \"$$f\" | sed -e 's/\.prc/\.po/' -e 's/\/PrinPRC/\/Pahts_Prin_PRP/'`" "$$f"; \
   done;
   PrpPack -c Pahts_District_Prin.prd
   rm -rf ./Pahts_Prin_PRP
   rm -f Pahts_District_Prin.prd
   cp ./Pahts_District_Prin.prp $(URUDIR)

Makefile Explanation Show Spoiler

Unpack the Prin.prp file.
Decompile all the DrawableSpans objects to PRC, edit them to reference the FogEnvironment, and recompile them. This has the side effect of recompressing all the geometry too, which results in a smaller file.
Compile all of the PRC files in a ./PrinPRC folder and copy them into the unpacked PRP.
Repack the PRP.
Clean up left over folders and files.
Copy the newly modified Prin.prp to my Uru folder.

EDIT: Forgot to mention... yes, I am crazy

[Branan]

Fog Environments are the "right way" to do Fog in Plasma... But the artists all got used to using the fni files for that. Those fog commands were originally intended just for debugging purposes.

My source on this is actual code comments

[Paradox]

Fog Environments are the "right way" to do Fog in Plasma... But the artists all got used to using the fni files for that. Those fog commands were originally intended just for debugging purposes.

My source on this is actual code comments

The problem with FogEnvironments is that it's easy to have two rooms, one with blue fog and one with green fog. If you look from one room through a doorway into another, you see the other colour of fog, which is a somewhat jarring effect. The "fallback" how Plasma currently does it is a pretty good strategy (give the same FogEnvironment to every object).

The reason I used FogEnvironments in the Pahts nexus is because it was entirely self-contained, so there was never a chance of "bleed through" elsewhere.