6/4/97

Scalability
* How low do we go?
* OpenGL is too high for some people
* Want to try to span as large as range possible
* Core & vertical extensions
* Should being able to write VRML browser be a goal?

Do we provide Java bindings? Probably.

How do we handle differing results on diverse platforms?
Should we provide behavior support? It might be good to get scene
graph only defined
Should work from setup (or at least keep it in mind) to high-end.

-----

Sharon Clay: Perfomer Presentation

* Toolkit not API in sense that API gets broken when necessary
* Provides diagnostics
* MP sorting:
- runtime decisions for scalability
* libpf/libpr:
- distinction between low-level rendering and s.g., allows efficiency
* GeoSets:
- packed/interlaced formats not supported at same level as separatedcoordinate sets.
- more flexibility in indexing would be good.
* GeoStates:
- Overrides aren't too fine-grained because state sorting requirestheir consideration.
* Display Lists
* MP - app/cull/draw model
* Dynamic data & frame accuracy

* How different is code across machines?
- libpr: state sorting, texturing
- libpf: fewer changes, some for multipipe

* Things to be done better
- Extensibility -> need benchmarking framework
- Indexes
- Notification is missing, especially for UIs
- MP - fork model vs. sproc
- Multibuffering & subclassying frame accurate or not is hard
* Behavior Support
- Mechanism not policy
- Different databases have different behavior
- Code as part of database: callbacks can be included ; call into dsos.
* Nodes are approx. 1-10% of data
- geostates are bulk of it -> node duplication is "OK"
* Error checking on configuration, not during operation
* Runtime Statistics
* Culling Algorithm
- View frustum culling: spheres @ nodes, boxes @ geosets.
- Callbacks in culling allowed
- Culling and chunking are somewhat at odds - scene graph modeling issue?
- Editing an in?? tstri p is bad
* LOD: lots of automatic stuff
- Bounding box & sphere overrides
* Collision: Intersection traversal: segment intersections


Kevin Rushforth: Java3D
* Behavior as extensibility
* Synchronization of behavior with drawing?

>>> Kevin presented about a dozen viewgraphs, which I don't reproduce here.



Feng: Intel Scene Manager
* Performance, targeted to games
* Toolkit, not API
* Cross platform not a concern
- What level of 3D cards do you run it on?
* No scene graph processing (e.g. spatialization)
- Does do state sorting
* Provides BSP node/Gridsort action
* Action object
- Simple: action run before next frame is drawn; behavior mechanism
* Simple view/Camera model
- Camera is separate from the scene graph
* Flattening similar to Performer
- Immediate & retained modes
- No compiled mode
* No callbacks
* All parts of scene graph are modifiable
* Nodes can have multiple parents
* No occlusion culling
- But have an app-culled flag
* 2.0 adds more primitives (a la Java3D/OpenGL++)
- Adopting fields for MP protection
- behavior: VRML & Java3D behaviors
* Discussion of behaviors: What is the use?
- Useful for storing behavior with databases a la VRML
- No one uses ISM behaviors
* Collision detection
- No global detection, but you can check for it.
* precompute bounding boxes & flatten xforms
* Every node (including shape) has xform information
* Spatialized audio
- uses RSX
* Distributed support
- Events (only) transmitted across network
- Multicast / TCP/IP (reliable, server established when game starts)
- Data duplicated, not distributed
* switch LOD
- Multiplication factor in camera



Peter Birch: Inventor

>>> Peter presented a half-dozen slides which are omitted here.

Goals Discussion
* Multiple contexts means multiple pipes/windows
* Describe lower level framework
- Minimal functionality with nodes to do more complex stuff
- How should higher-level stuff be packaged?
- Want something useful, but better to provide less that's right than
more that people don't want.
* Performance vs. Flexibility vs. Ease-Of-Use
- Tradeoffs
* A Specific Feature
- Frame rate control
* Lessons from Optimizer on C3D
- Extensibility of nodes/actions
- File r/w extensibility
- MP support
- Single vs. double
* Take 1st issue - set/get
- e.g. Transform:
setMatrix, getMatrix (bloats API "file reader issue")
container based API
- Vertices: field-based, vertex.get, vertex.set
for notification, requires container pointer
(container API has a profusion of methods)
- Gets: In MP case, where is the storage?
Lazy write? Multiple copies?

6/5/97

Should we ship a toolkit with OpenGL++ to, e.g., do windowing/events?
Richard says no.
David suggests that we provide enough to write a basic program.

More set/get Container discussion

container.setField container.field.set
container.getField
- API bloat - need ptr to container
- field storage hidden (for notification)
- need way to get field handle - field impl. more exposed
- must avoid cntr1.foo = cntr2.foo

Use get method to retrieve data members

Reasons for fields
- hide MP stuff
- hide impl. details
e.g. dirty bits; notification schemes

Avoid operator overloading
but if not provided, people tend to add it themselves
so keep it at reasonable level - can lead to possible performance problems

Issue: ISM does pure fields


Extensibility
possible meanings:
add new containers (scene graph objects)
subclass existing containers
add new field types
add new traversals

app writer | extender | library maintainer
( no source code ) ( source code )

fields should be easy to add; just templates with set/get

chance to decide which things are hard/easy to extend

extension times:
- compile time
- dynamic library
- on the file (e.g. reading a file)

adding traversals:
only lib maintainer can extend container traversal unless duplicated

traversal extesibility so people can work over the scene graph themselves
- can do w/RTTI on containers
- action table

For, e.g. file reading, need creation by name (or id)
e.g. switch(name) {
case material:
new material;
case transform:
new transform;
}
but need code to extend

runtime id
creation id
string to id

---

Error checking
do as much as we can with minimal performance impact
debug library or not?
two version -> differing behavior
spec should be clear about what's an error and what's not
out-of-memory errors: what kind? OpenGL or other?
extendible errors

How does COM fit in?

Can get Java wrappers automatically, maybe
Java issue: e.g. getNode must tell Java what node type it is through,
e.g., RTTI
garbage collection can garbage collect things unexpectedly;
implications for performance predictability

Doubles vs. floats
Digital is concerned about doubles

Other data type issues
- what do we really nedd doubles for?
some geometry
- bytes & floats for colors

transparency:
want to be able to be specific,
but also let library pick best thing for machine
conflicts between alpha blending in appearance and transparency
in material ISSUE

same or similar issue for texture

runtime extensibility
on the fly extension is painful
-> can macroize, but can't ad new methods when reading a file
Inventor/Performer style dso/dll loading requires initialization

runtime field addtion seems like overkill

Support Inventor/Performer style dll loading

Extending containers & traversals can pose problems with multiple
extension sewed together: they may not be compatible and we won't
address this.

Actions:
method executed per container during traversal
container-specific operations
traversals: string together several or combine into one

make intermediate results exposed
-> can avoid this in many cases
if node methods are virtual, can add node-level behavior during
traversal
but there's pressure from Performer,
e.g. calligraphic lights
possible other algorithms
static appearance sorting is an option: sort once up front

exposure introduces synchronization, protection concerns

How are things exposed? Not clear?

Need to build intermediate representations
Flag nodes?
Build new graph over nodes?
Appearance: can't change these for deltas
use bitvectors to say what's important?

Separate "nodes" from a (general) graph structure that points to nodes?

LOD has an issue in this scheme
Treat LOD "node" as a special "scene graph" node

Doesn't solve problem of where to put intermediate data from traversals

Maybe Liquid Reality did this?

-----

Binary format discussion

special mechanism for r/w binary formats
putting r/w support in fields w/ virtual functions is bloaty

leave out support for this?
Too important for debugging and transmission in network environment

There are things outside the scene graph that may be separate
e.g. view/camera

but camera may ned to be tied to the s.g. but it may also want to be
not in the s.g., esp. if there are multiple scene graphs to render.

not clear if camera should be saved/read or not

do all objects need to be derived from a single object?
not necessarily

Basic types

Make basic types OpenGL types

Basic types are OK
make same as OpenGL basic types, but different prefixes
Enums: same as OpenGL

Composite types

math functions too limited
how much to put in there?
-> in any case, fix the current stuff

Bitmask is arbitrary length: needs fixing

Merge atomic and composite fields

Bounds

Are bounds an object that is extensible?

make around, etc. take general (unspecialized) bounds

not ref counted, so need to copy

merge single/multiple object builders in API

change pt1, pt2 to ray object

Other bound types:
non-axis aligned box, convex hull, ellipsiod, cylinder for reg group

Ref counting
need it, but it's annoying
pick one, e.g. COM: auto delete when go to zero

6/6/97

Issues
------

Image class

Texture format
- internal
- external
- relationship to images

Support for picking
- more general intersection / specific picking traversal

Highlighting
- look at Optimizer
- multipass questions

Transforms with multiple parents & MP traversal

Clarify lack of order for traversal of children

fieldInfo

Animated texture support
- may tie in w/morphing

Transform node
specification
ways to set/get

error checking
conformance
performance analysis tools
versioning/compatibility
Java/C bindings

antialiasing is missing
-may interact w/transparency

face culling rendering modes
-where? vs.
point/line size missing object properties

specular/emissive defaults wrong

MP
- traversals

Appearance
group state
should texgen, etc. be separate
extensibility by addition

Environment node
- bounding volume

Alpha in colors
descriptive vs. procedural
transparency vs. alpha blending

LOD issues
texture, geometry, image, behavior

cleanup basic types
class hierarchy diagram
indexed_set vs indexedset_

hints
- display list
- caching

Stencil?

Text
2D or 3D

Decoupling of graph from nodes

VRML support

Packaging non-core stuff

Imaging

Time & media
- frame rate control

Engines & routes

Resource management

Windowing/Events

Audio
- 3D
- drivers

Loaders

motion & velocity
operator overloading

database paging

benchmark frameworks
(tied to conformance)

compressed geometry (LOD)

overlapping multiresolution representation

---

Should OpenGL++ have its own context?
Performer has state shadowing

Text:
Need both billboard style 2D text and extruded text?
Seems like 2D text that isn't a texture would be good

Behaviors:
Changes to one node affect changes to others
or done by modifying nodes

Framework for efficient scene graph updates
- when is a good time to modify?

Divorce routes from core
- need notification anyway

Sensor nodes notify too

Register interest in a field or container

granularity
mechanism: callback
or list that's queriable
efficiency/spece tradeoff

update lists vs. cycle buffers
update lists for sparse changes
cycle buffers for big changes
SGI investigating a third model for asynchrony

Asynchrony required for potentially unbounded processor computations

Need to be concerned with 1-4 processor machines

May do something different with few processors vs. many

Keep a list of things to solve with notification

VRML notification

nodes are different for impl. efficiency in OGL++

support for modelers:
can be hard to map modeler's data structures
if nodes aren't identical
applications burden to keep track of differences
user data pointer

adds work: routes & engines

proto nodes can be trouble if done as more than macros

How important is it? Should we support/provide a VRML loader?

Asynchronous vs. synchronous notification

Richard will investigate threads/contexts on PC (Windows)

Course grain MT rendering, e.g. 2 parts of a window, we should handle
Finer grain is for OpenGL

Testing & Conformance
Keep a justification document
Make a scene graph page

Binary compatibility discussion
Try to reduce number of incompatible releases
ISV qualification issue

Media & Time

video/audio APIs differ
Is there an issue?
Controls that would be present in s.g. seem pretty generic
but is there more to it?

Time
Java3D's method (e.g.) w/ a single clock should work fine,
but not if there are multiple asynchronous clocks

Windowing & Events
Event traversal
Nodes express interest in events

List of things that would be layered (incomplete):
VRML toolkit
Performance analysis
Viewer/Manipulator toolkit (but there might be some simple basic stuff)
File loaders: geometry, images, movies, sounds ; binary file format
MP policy layer