Archive for Java

Planes, Textures, and Soft Shadows

My toy raytracer written in Scala got a few new features:

  • Planes
  • Textures
  • “Soft Shadows” (distributed raytracing)
  • Supersampling Anti-Aliasing

Textures don’t add much to the computation time, but distributed raytracing is a real performance killer (at least when implemented naively, as in my version). Essentially, when determining the surface color at a given point, instead of sending just one ray to a lightsource to see if it’s obstructed by any other object, many rays (typically at least 25) are sent out to an area that describes the light source (e.g. a box). The return values (black if the ray was obstructed, the light source color otherwise) are then averaged, leading to smooth transitions at the edges. And it does look nice… combined with supersampling (anti-aliasing) it now becomes easy to spend hours rendering a single image at, say, 1024×768 pixels.

Pool Scene

Next idea: writing a parser combinator for (a subset of) POV-Ray’s Scene Description Language (SDL) to skip the painful step of modeling scenes in compiled code. This will also enable me to do some Scala coding again, since adding new features to the raytracer itself usually means spending much more time wrapping your head around math stuff than actually writing code.

Advertisements

Leave a Comment

Everything Is A Sphere

When I was down with a cold last week I dug out a book about computer graphics that I bought during my university time (3D Computer Graphics by Alan Watt). It provides a mathematical foundation for many core techniques in CG, and it got me interested again. About 8 years ago when I bought this book I wrote a small raytracer in C++, and since I am really in search for new hobbyist projects to teach myself Scala, I figured I could give it another shot.

Scala is a statically typed functional/object oriented language for the JVM and the CLR, and at least on the JVM it is known for providing performance similar to Java (in contrast to dynamic JVM languages such as Groovy or JRuby). This is the first scene that provides something my 8-year-old project couldn’t, namely a checkered surface (composed of two other surface instances). The code is pretty newbie-like and a bit unstructured, so for now I’ll leave it at that. FWIW, it took about 5 seconds to render this picture on my rather mundane home machine (Athlon X2 @ 2.2GHZ, Windows XP) using the 1.6.0_11 server JVM.

A World of Spheres

Leave a Comment

Hello XO!

For learning a new language or framework, I tend to use tasks I’ve solved before – this way I’m more focused on the new platform instead of the problem itself. One such task is a sudoku solver, another tic-tac-toe. One rainy afternoon, trying to escape boreout at work, I mindlessly typed apt-get install tictactoe on my Ubuntu workstation, and I discovered that my Ruby tic-tac-toe client from 2002 is still in the Debian/Ubuntu repositories (and it actually works!).

I wanted to play around with Swing/Netbeans, so after a couple of evenings here’s the Java/Swing version (but this time, I hopefully did not mess up the negamax implementation): JTicTacToe (Webstart)Sources

It was actually quite fun, except that I gave up forcing an initial size for the main application window. Seems like there’s no easy way of achieving this with the Swing Application Framework.

Leave a Comment

Composite JSF Components

Writing a versatile input/output component for JSF, I realized two things:

  1. Composition works great. It is almost trivial to delegate encoding and decoding to existing components like the JSF core input tags via composition. Facelets templates offer this functionality in a declarative way without coding (or compiling), and I wouldn’t want to use JSF without them at all, but it’s nice that composition is rather easy in core JSF anyway.
  2. You don’t want to pull SelectMany values from ExternalContext#getRequestParameterMap(), but use ExternalContext#getRequestParameterValuesMap() instead.
  3. Doing a “render-time” iterator component similar to Facelets’ ui:repeat is insanely hard to do right. Really. Rendering the child components multiple times with different data is easy, but to let them perform correctly on every stage of the lifecycle is near to impossible without some intimate knowledge of JSF. I’d really like to read a book on these kinds of advanced JSF topics (and not on designing another calendar component), but I’ve yet to find one.

Leave a Comment

YourKit Java Profiler 7.0 EAP

Until now I did not really consider commercial Java profilers. The Netbeans profiler works most of the time and usually helps to identify the most glaring hotspots of an application.

Recently I stumbled upon a YourKit EAP build and was rather blown away by its ease of use, integration, and the snappy user interface. Enabling profiling on a local JBoss was actually a matter of one click, not of manually fiddling with agent and LD_LIBRARY paths. It also offers some JavaEE-specific statistics: plain SQL query execution times, as well as JNDI lookup and JSP/Servlet statistics (no JSF-specific stuff yet). And most important: all profiling tasks can be started and stopped at runtime, thus you don’t have to endure a slow application server startup just to profile one page (as with Netbeans). The EAP builds are apparently full builds with no restrictions (except of being beta software), so if you’re looking for a slim, working Java profiler I’d take it for a ride.

Comments (1)

TestNG and Groovy 1.1

It really is that simple:

import org.testng.annotations.*;

class GroovyTest {

@Test(groups = [“demo”])
void groovySuccess() {
assert 1 == 1
}

@Test(groups = [“demo”])
void willFail() {
// prints java.lang.AssertionError: Expression: (1 > 2)
assert 1 > 2
}

}

The only downside I found so far is that you cannot annotate the whole Groovy class with @Test, since Groovy defines additional public methods that TestNG mistakenly treats as testcases.

Leave a Comment

JSF/MyFaces f:selectItems and automatic converters

JSF converters provide a way for mapping complex Java types to the UI. A class converter is registered for a type and is then called every time an object of the given class is rendered to the UI (or posted from a form), unless another converter is specified. For example, registering the following converter in your faces-config.xml provides automatic conversion of Enum values (a similar converter is already included in JSF 1.2, but missing in 1.1):

<converter>
<converter-for-class>java.lang.Enum</converter-for-class>
<converter-class>com.dlicht.converter.EnumConverter</converter-class>
</converter>

With this, you can for example use Enums for selectItem values. What I did not fully realize and what cost me hours before I stepped through the MyFaces source is that the converter is determined through the input component’s value mapping type, not the value type of the selectItems themselves. Although this does make sense (because it’s the bean property that represents the the component value, and not the current selectItem, and the selectItem values of a select list don’t even have to be of the same type), it’s not entirely trivial. For example,

<h:selectOneListbox value=”#{myBean.enumProperty}”>
<f:selectItems value=”#{myBean.enumValues}”/>
</h:selectOneListbox>

works without an explicit converter, but

<h:selectOneListbox>
<f:selectItems value=”#{myBean.enumValues}”/>
</h:selectOneListbox>

does not.

Comments (1)

Older Posts »