The Visualization Overview section is now available in my growing tuning series. I struggled with being somewhere between a catalog of functionality (and going too deep), an API overview (and being too shallow), and a design justification (and getting too long-winded).
Ultimately, the idea of the system overviews is to provide enough information so that the tuning pages I’m going to create have some context on what I’m tuning without me having to do it in-line and detract from the actual tuning content.
I just added some background information on the packaging assembly as part of my documentation set for experiences and insights on tuning the Ikosa framework.
Finally finished off and published the first (non-bloggish) page of a “series” of pages I’ll be adding to (eventually) that I’d collected thoughts on about optimization stuff in the Ikosa Framework.
It’s been just slightly over a year since any substantive post. Again, as the sole resource on Guildsmanship (Ikosa Framework), I get more from the coding than from promoting to the small set of people who are even slightly aware I have been coding the D20 system (v3.5) for the past decade (or so).
Last January: more furnishing things (mostly model generation)
February: even more furnishing things such as drawers and doors opening, UI workshop, in-game manipulation actions; ended with some drawing optimizations in the workshop and client
March: continuing on optimizations
April: even more optimizations (it’s easy to get addicted to performance numbers!)
May: got back into furnishing movement (push/pull/slide/rotate); also got into climbing, moving on furniture; and UI bound jump-down and hop-up actions
June: (slow month) but I added a new ModelCacheSelector; and here’s a quoted comment from a check-in: “Furnishing default implementations tend towards solid convex cuboids
overrides for hollow/cabinet/surface mainly change covered face exposures” (which I think was a refactoring to a base-class so I didn’t have to copy/implement certain geometry features)
I’ll add some more later today while I’m on a roll.
Lest I appear idle due to a lack of posts…
And a small sample of the check-ins over the past few weeks:
Putting all the fragments together gives the basic shape of a meta-model, but doesn’t explain how to get to this:
The first thing to do is to define the set of brushes that can be used to paint the miniature. This is done by opening the “brushes” node for the meta-model in the package explorer.
Resulting in the brushes editor:
From within it is possible to add colors, images, gradients and stacks. Colors are pretty self-explanatory, they are solid colors. Images are images available to the model either bound directly to the part, or referenced as a resource in the package. Gradients are linear gradients based on WPF gradient brushes. Stacks are sets of brushes that are overlain on top of each other (assuming that the upper brushes have some transparency. Stacks allow multiple directionalities to gradients within a brush.
Next, opening a gradient brush shows the gradient editor:
The directionality of the gradient is selected via the array of buttons with arrows. The gradient stops are modified in the list box and buttons on the right side. The slider to the left of the gradient stop list box specifies the gradient stop relative location for the currently selected gradient in the list. The striping effect of the gradient is controlled by the “spread” combo and the slider next to the combo (which determines how the pattern repeats when it ends and how often the pattern repeats).
Now, to the actual painting back in the meta-model editor.
The “brushes” tab lists all the named areas that can have brush references mapped, and the currently mapped reference. Right-clicking one and selecting “assign” brings up a visual list of all the brushes that can be applied.
These references are the “global” (for the meta-model) brush references. It is possible to apply variations to individual fragment instances; and this applies to brushes as well as “parameters” such as lengths and radii, and to place more than one fragment in a reference connector.
For example, on the left arm, the first “arm.xaml” segment connected to the torso doesn’t have anything mapped for the “arm” brush, but the “arm.xaml” mapped in it’s “connector” has it’s “arm” brush overridden to be sleeve, which is effectively a reverse direction of the “shirt” brush so that the visual jump at the elbow isn’t so jarring.
Also, I mapped another segment “balljoint.xaml” to the left-arm slot on the torso to create the slightly bulging shoulders.
Finally, to reduce the relative thickness of the forearms, I select the forearm segment, switch to the “doubles” tab, unselect the “yield” checkbox for arm-diameter and freely adjust the diameter.
Spell components (component pouch, devotional symbol and verbal).
Map redraw on invisibility state changes.
Creatures: bugbear, hobgoblin, orc, kobold, half-orc, gnoll, ogre, grimlock (light-sensitivity, weapon proficiencies, giant-type)
Classes: barbarian, rogue, ranger
Tacticals and class-features: evasion, improved evasion, rage, trap-sense, sneak-attack, uncanny-dodge, flanking, overrun, legal-position checks
Prerequisites now part of LocalViewer instead of a docked tool window, fixed some minor problems with responsiveness of controls,
Made single option, check and save prerequisites work with button arrays instead of combo-boxes.
Fixed poisonous natural weapon process flow and binding on spider’s bite attack.
I also spent some time working on trying to work out non-tactical settings and regional settings; but nothing that I can add into the core of the experience just yet.