To debug lighting, it is handy to visualize per-vertex normals. Traditionally, one would create a vertex buffer with a bunch of lines representing normals and render this after rendering the mesh itself. This works but it is not nearly as simple, or as cool, as using a geometry shader.
You can write a trivial geometry shader to visualize normals. The shader takes a triangle as input and outputs 3 lines that represent the normal for each vertex. In the first pass, render the mesh as you normally would. In the second, pass enable the geometry shader and render the mesh again. That's it. No extra vertex buffer, just an extra pass.
As Deron predicted way back in January, our product has been renamed. What you have come to know as Point Break is now called Insight3D. Usually developers resist name changes but we're all pretty happy with it. We hope the name change doesn't cause too much confusion for you. In memory of our original name, I've modified the Surface Mesh primitive example in our HowTo to use our original logo for the texture:
We don't have a new logo yet but you should have high expectations.
In other news, we are thrilled about the amount of interest Insight3D received at this year's User's Conference. Thanks to everyone for their feedback and ideas. If you have more to say or want to request an alpha version, email Insight3D@agi.com. Our team has quite the track record of making changes based on customer feedback. In fact, Bart immediately started coding things based on customer requests from the User's Conference, after he returned in the "party van."
The slides for our Insight to Insight3D presentation from the UC are available under Primers on our User's Conference page. They assure me that the log-in is quick and painless. For other Insight3D resources, check out our online help or this past summer's special edition Inview. The Inview contains two articles on Insight3D (called Point Break back then). We were excited to meet many people at the UC that read the Inview and wanted to learn more.
Rendering objects over large distances is common for geospatial programs, and when done incorrectly, the objects may visually jitter. Here, an object is made up of any combination of triangles, lines, and points, like a 3D model. The problem becomes more noticeable as the viewer nears the object. The following video demonstrates this using STK. (Note that I had to modify STK as it does not ordinarily exhibit jitter.)
Rotating about the space shuttle from far away, there is no jitter. After zooming in, the jitter is readily apparent. In this blog entry, I'll discuss the cause of this problem and the solutions used in Point Break and STK.
Our new text rendering code is 5x faster (in a bad case) than our STK code - and the new code uses the same algorithm! How's that work? Well, we are using the same algorithm but the implementation is vastly different. In this post, I'll describe the new implementation, which offloads work from the CPU to a vertex shader running on the GPU, enabling the use of static vertex buffer objects.
We just returned from the annual SIGGRAPH conference, and one thing is clear: it's an exciting time to be in computer graphics. There was an overwhelming amount of things to see. The Larrabee, GPU, and OpenGL presentations were among the best in my opinion.
Fall recruitment season is only a month away. Good timing. Our 3D team is working on lots of interesting problems in the fields of computer graphics and software architecture. In fact, we have so many interesting things to do that we need your help.
Specifically, we’d like to talk to students in computer science, math, engineering, or other hard majors, who are seeking internships for next spring or summer. Both undergraduate and graduate students are equally encouraged to contact us.
The alpha version of Point Break is now complete. For an alpha, it is packed with features, documentation, and examples. I also expect it is more stable then most alpha software; well over 20,000 lines of unit test code have been hammering on it several times a day for months. If you're interested in trying out the alpha, contact Tom Urie at PointBreakAlpha@agi.com.
Before I provide an overview of the major features, I'll show two example projects that ship with the SDK. We’ve blogged a lot about the data structures and algorithms deep inside Point Break, but we've rarely shown it in action – these examples will change that. Since we know there's no better way to learn an API than by example, we've provided the HowTo project shown in the video below.
View the higher quality .avi (31.6 meg) if you want to be able to read the text in the video.
This example presents many of the component's capabilities organized by namespace and object. When the user clicks on a task, the 3D window is immediately updated. In addition, the code used to create the visualization is shown in the code view for easy copy and paste. The HowTo actually reads its own source code to display the code.
I'll discuss using a bounding sphere for occlusion culling today. The basic idea is that large objects, occluders, are likely to occlude smaller objects in a scene. In Point Break, an obvious occluder is the Earth, and satellites, ground stations, vehicles, et.al. are objects likely to be occluded. Occlusion culling applied in this manner is sometimes called horizon culling, since objects are no longer visible when they go below the horizon.
I recently read an entry in the Journal of Ysaneya regarding horizon culling that got me thinking about the topic again. (Check out Ysaneya's blog for incredible planet and space screen shots from his game under development. I know you'll be asking when we'll be able to render such amazing scenes.) We have horizon culling code that is very fast, but is sometimes wrong. For Point Break, we needed to address this.
We're taking a break from Point Break to discuss how STK's Solar Panel Tool calculates its numbers. STK's Solar Panel Tool is used to estimate the amount of power that solar panels generate at a given time. If you are unfamiliar with the tool, search for "Solar Panel Tool" in STK's Help to learn how to use it. The tool uses a graphical rather than analytical approach to determine power.
Triangulation is the process of decomposing a simple polygon into a set of triangles. Recently, a customer uncovered a bug with our triangulation algorithm. The customer defined the boundary of a polygon that would be rendered on the earth. Our code failed to triangulate the polygon due to a precision issue. Additionally, the customer was creating multiple polygons to work around the fact that our code does not allow for holes inside a polygon.
We knew that we were going to rework our triangulation code for Point Break and a customer had an immediate need, so we bumped up the work's priority. While our current code generally works, it has significant speed and precision issues. So, we decided to start anew.
