X-Git-Url: http://www2.svjatoslav.eu/gitweb/?p=sixth-3d.git;a=blobdiff_plain;f=doc%2Findex.org;fp=doc%2Findex.org;h=04f785f64fb6d0934a6dbb4f08c9307043e69356;hp=6f974efe82ec4d397a5d06435e4e5e0accf40af9;hb=7415236b125f8b0981c5f2e7c83475370caf4b63;hpb=581fa47296d1c583331b454eae59d5555d432b1a

diff --git a/doc/index.org b/doc/index.org
index 6f974ef..04f785f 100644
--- a/doc/index.org
+++ b/doc/index.org
@@ -27,36 +27,49 @@
 #+HTML_HEAD: </style>
 
 * Project description
-In software, pure Java realtime 3D rendering engine. With the final goal of
-becoming a platform for buildng 3D user interfaces.
+In-software, pure Java realtime 3D rendering engine. With the final
+goal of becoming a platform for buildng 3D user interfaces and
+interactive data visualization.
 
 + See: [[http://www2.svjatoslav.eu/gitbrowse/sixth-3d-demos/doc/index.html][demos of current 3D engine capabilities]]
 
 
 System is implemented in Java because:
-- It scales well to handle great complexity.
 - It is easy to refactor and experiment with.
-- It is fast enough thanks to Java virtual machine just-in-time compiler.
-- Easy to run on various hardware platforms and operating systems.
 
-3D rendering is done in software, 100% pure Java on CPU. At least for now.
-Modern CPU cores count keeps growing and therefore rendering by CPU is not as
-expensive as it used to be for the old single core systems.
+- It scales well to handle great complexity.
+  - Allows to implement clever performance optimizations (instead of
+    going for GPU offered brute-force rendering approach).
+
+- No limitations imposed by:
+  - requirement for decent GPU
+  - GPU missing features
+  - GPU missing/incomplete/buggy drivers
+  - OpenGL specification
+
+- It is fast enough thanks to:
+  - Java virtual machine just-in-time compiler.
+  - Growing CPU cores count.
 
-CPU rendering performance is already good enough to implement usable 3D UI at
-sufficient detail level, resolution and frame rate.
+- As a result it is easy to run on various hardware platforms and
+  operating systems.
 
-Pure Java also means easy portability and installation. No need to deal with
-platform specific dependencies.
+3D rendering is done in software, 100% pure Java on CPU. At least for
+now. Modern CPU cores count keeps growing and therefore rendering by
+CPU is not as expensive as it used to be for the old single core
+systems.
 
-Also CPU rendering allows to easily test different rendering algorithms and
-retains complete control of every rendered pixel.
+CPU rendering performance is already good enough to implement usable
+3D UI at sufficient detail level, resolution and frame rate.
 
-* Software development
-** TODO
-+ partial (region) frame repaint
-+ antialiazing
-** Instructions to embed Sixth-3D in your project
+Pure Java also means easy portability and installation. No need to
+deal with platform specific dependencies.
+
+Also CPU rendering allows to easily test different rendering
+algorithms and retains complete control of every rendered pixel.
+
+
+* Instructions to embed Sixth-3D in your project
 Maven *pom.xml* file snippet:
 #+BEGIN_SRC xml
 <dependencies>
@@ -81,3 +94,41 @@ Maven *pom.xml* file snippet:
 #+END_SRC
 
 See [[file:codeGraph/index.html][generated code graph]] using [[http://www2.svjatoslav.eu/gitbrowse/javainspect/doc/index.html][this tool]].
+* TODO features to add
++ Partial region/frame repaint: when only one small object changed on
+  the scene, it would be faster to re-render that specific area.
+
++ Once partial rendering works, in would be easy to add multi-core
+  rendering support. So that each core renders it's own region of the
+  screen.
+
++ Antialiazing. Would improve text readability. If antialiazing is too
+  expensive for every frame, it could be used only for last frame
+  before animations become still and waiting for user input starts.
+
++ Render only visible polygons.
+  + This would significantly reduce RAM <-> CPU traffic.
+
+  + General algorithm description:
+    + For each horizontal scanline:
+      + sort polygon edges from left to right
+      + while iterating and drawing pixels over screen X axis (left to
+        right) track next appearing/disappearing polygons.
+        + For each polygon edge update Z sorted active polygons list.
+        + Only draw pixel from the top-most polygon.
+          + Only if polygon area is transparent/half-transparent add
+            colors from the polygons below.
+
+  + As a bonus, this would allow to track which polygons are really
+    visible in the final scene for each frame.
+
+    + Such information allows further optimizations:
+
+      + Dynamic geometry simplification:
+        + Dynamically detect and replace invisible objects from the
+          scene with simplified bounding box.
+
+        + Dynamically replace boudnig box with actual object once it
+          becomes visible.
+
+      + Dynamically unload unused textures from RAM.