Archive for May, 2006
ThreeD is an object-oriented rendering engine package written in Java. The ThreeD graphics pipeline is designed to support the transformation and visualization of Entities, each of which are subclasses of objects which encapsulate their own rendering and transformation algorithms and conform to a specific interface. The engine supports a switched, double-buffering scheme for the image buffer and the Z-buffer, using a support thread to clean buffers before use.
The current implementation contains a single Entity subclass: The Polygon class. The Polygon class renders polygons in three dimensions (using homogeneous coordinates) with perspective transformation using the Z-buffer for hidden surface removal. Each Polygon has a uniform RGB color, and the rendered color is adjusted by a primitive lighting component based on the dot product of the Polygon surface normal and the view vector. Polygons are rendered using an integer scanline algorithm. Anti-aliasing and texture mapping are not currently supported, but the class could be easily modified to support these (and other similar) features.
Performance notes for v1.0, circa 1996…
The performance is somewhat less than I had hoped for. The average performance of the Test applet shown above is (running via Netscape 3.0 on a PowerPC Macintosh, 200×200 applet geometry):
|Entities Rendered Per Frame:||384|
|Average Render Time Per Frame:||0.75 seconds (+- 0.05 seconds)|
|Average Frame Rate:||1.33 frames/second|
|Average Entity Rendering Rate:||512 entities/second|
The Test applet writes real-time performance statistics to the Java console, so you can gauge the performance of your browser and machine. The multi-threaded environment causes a few wrinkles in screen update management, since there is no synchronous method to force an image frame screen redraw. The solution is to use synchronous locks on the buffers to control write access and preclude buffer modification until the buffer has been appropriately read. Consequently, a non-trivial fraction of the rendering period is consumed while waiting for the screen update to complete. The double-buffering strategy is meant to address this, but the lack of a fast array assignment method in Java reduces its effectiveness, as it takes a significant amount of time to reset an entire buffer to zero.
Performance notes for v2.0, updated in 2006 for Java 1.5…
Hardware and JVM performance has certainly come a long way in 10 years. I recently updated the code for Java 1.5, and I found that I had to throttle back the frame rate to get acceptable visual clarity – the engine can render a frame faster than the JVM can refresh the screen, even at the double size (400×400) of the current applet above. Java now provides more extensive double-buffering and synchronous screen update mechanisms, and these permitted me to remove many of the hacks I needed back in 1996 with the original implementation running via Netscape 3.0.
Here are some typical stats for the updated code on Firefox 1.5 using the Java 1.5 browser plugin (400×400 applet geometry):
|Entities Rendered Per Frame:||384|
|Average Render Time Per Frame:||0.02 seconds|
|Average Frame Rate:||40 frames/second|
|Average Entity Rendering Rate:||38400 entities/second|
This is an implementation of a meshwarping algorithm, using polygon scan conversion with texture
mapping to produce the warped image. On release of the mouse button after modifying the position of a vertex, the four affected polygons incident on the modified vertex are rendered with a relatively standard Bresenham incremental scanline conversion algorithm, using the initial fixed grid polygons of the image as textures to be mapped onto the new polygons. The algorithm is lossy, in that the texture mapping does not integrate areas of the source textures to produce pixel values. The texture mapping is also prone to distortion along the edges of adjacent polygons, which can produce unrealistic results. Vertex adjustments are reversible and idempotent.
Ultimately, it’s more toy than serious graphics tool…but fun nonetheless.
- Siri – a Shot Across Google’s Bow
- “Is colocation cheaper than using a cloud computing service to run the same workload?”
- “How Big is Amazon’s Cloud Computing Business?”
- “Android will run majority of smartphones by Spring”
- Amazon EC2 I/O Performance: Local Ephemeral Disks vs. RAID 0 Striped EBS Volumes
- “We create 5 exabytes every two days.”
- “Go Screw Yourself, Apple.”
- “You are not Google. (or: you don’t really need NoSQL…)”
- “The largest cloud providers are botnets.”
- Observed Performance of Amazon EC2 Instances
- Cloud Computing and Mobile Devices
- Time and Clock Issues in Windows-Based EC2 Instances
- My experimental local and real-time search engine is now available
- Entropy in Cloud Computing Applications
- How to Jailbreak iPhone 3.01