HOME
OVERVIEW
FUTURE
SCREENSHOTS
PEOPLE
SOURCEFORGE
NEWS
TUTORIALS
LINKS
DOWNLOADS
FUTURE

Outline of ideas for the future:

  1. Open Source Software Philosophy
    1. Don't re-invent the wheel -- reuse any applicable pieces from other Open Source Software projects
    2. Allow other OSS projects to reuse SuperConductor code
    3. Give SuperConductor a 'life of its own' so that it may perpetuate if original authors no longer participate
    4. Leverage development -- if other users and developers stop inventing new Render Controllers and just use and improve SuperConductor, more development is focussed on shared code, and more users will benefit.
    5. Utilize SourceForge for hosting of project development
  1. Basic Design Concepts
    1. Portable, lightweight, responsive, non-modal UI.
    2. Program should be designed around abstract conceptual behaviours (find nodes, select job, start/stop job)
    3. All implementation details of each behaviour should be hidden behind API of runtime-loaded plug-ins
    1. Plug-ins will allow for modular customization, upgrading and enhancement of capabilities
    2. Plug-ins should enforce object-oriented design and access control barriers
    3. Qt 3 provides support classes for discovering, acquiring and utilizing plug-ins at runtime
    1. All specific support for a given 3D rendering application should be defined within plug-ins
  1. Useful Behaviours and features (study other projects to determine more) Not all are critical.
    1. Detect candidate computation nodes automatically
    1. Different OSes and network types may offer different ways to do this
    2. Nodes that can not be automatically detected should be manually add-able
    1. Detect info about candidate node automatically
    1. Different OSes and network types may offer different ways to do this
    2. CPU speed and quantity, RAM, available storage, mapped drives, network speed, net lag
    3. Enter critical info manually if unavailable
    1. Deploy/Install client-side software automatically if necessary and possible
    1. Check version of client renderer software
    2. Some computation applications may have minimal client
    1. Some computation applications may have heavier client but can use smaller remote-launcher
    2. Run client from Common network share
    3. Use admin shares and SMB under NT to deploy software
    1. Dispatch multiple jobs to different client renderers on client machines based on criteria (speed, memory, etc)
    2. Display abstract of job info
    1. Customize basic per-project settings (Start/End frame, etc) before dispatching job
    2. Verify scene dependencies (available paths, necessary external files, etc)
    3. Up-to-date node status during rendering
    1. Preview image in progress or last image if possible
    1. Verify integrity of output frames allegedly written (detect corrupt or empty images)
    2. Deactivate render nodes that crash or produce corrupt images. Reschedule task(s) to others.
    3. E-mail reports regularly or when certain events occur (job complete, machine die, etc).
    4. Group sets of nodes for common administration
    5. Custom batch plug-in set for easy basic extension to new software without new plug-ins
    6. Request screen grab from client as JPG to monitor status without remote-access
    7. Local client monitoring/control app -- show's current utilization of machine, inform Controller of (un)availability of client machine.
    8. Extensive logging of all actions for remote monitoring and post-mortem debugging.
    9. E-Mail logs
    10. Jobs can be set to deferred status to launch when criteria are met (time, CPU or network utilization, number of available machines)
    11. Launch-able by command-line from script?
    12. Gather usage statistics for all machines/jobs.
    13. Job priority, submitted user info
    14. Frame Slicing?
    15. Statistic Graphs for all participating machines: CPU, RAM, Swap, Net?
    16. Inter-job dependencies Job B waits for Job A to be complete before starting. Job C can run while Job A or B is running. (See item Q)
    17. Dispatch multiple frames at once to a node to decrease data load times.
    18. Specify number of CPUs to use for multithread-capable client renderers on multi-CPU machines
  1. Proposed target render client applications
    1. World Construction Set / Visual Nature Studio
    1. WCS6 now has network render control APIs
    2. VNS1 does not.
    1. Lightwave 7.x ScreamerNet Mode 2 or 3.
    1. APIs publicly available now. APIs are proven and tested.
    1. Max 4.x
    1. Status unknown.
    2. Max already has a Queue Manager.
    3. Some WCS users have evidenced a willingness to try to implement Maya support.
    1. Maya
    1. Status unknown
    2. Some WCS users have evidenced a willingness to try to implement Maya support.
    1. 'Custom' script-based client
    1. Not specific to any rendering software
    2. Allows advanced users to specify scripts that SuperConductor should run to implement each behavior, allowing it to be customized to unforeseen apps. Also serves as a basic reference for building new plug-in implementations for future target render client apps.
    3. Should allow for inserting numerous 'escape' codes into command strings to pass useful info (frame numbers, etc) from SuperConductor to user's scripts.
    1. POV-Ray
    1. Unsure of availability or appropriateness of any existing APIs, but application is all command-line driven.
    2. Use SSH to invoke on remote machines.
    3. Popular free raytracer, very slow, could greatly benefit from distributed controller.
    4. Possible to support single-image slicing as raytracers are point-sampled with no inter-pixel dependencies.

© 2002 3D Nature, LLC.
Site by Brazilian