No, this post is about combining cool PV3D features in order to achieve a nice looking animated sun. I’ve used the trunk of the papervision code repository, revision 851 (it works up to r910, after that a bug was introduced). Note that I’m no PV3D guru; I’m just sharing what I’ve learned so far.

Closely watch that corona for a while!

How it works

In short: the sun exist entirely of planes, controlled by alpha ratios and always facing the camera:
• one plane with a gradient texture white to red with glow
• two planes with a perlin texture, that resize and tag eachother as to provide a continuous outwards motion
• one plane that acts as a mask for the other planes to provide a perfect circle giving the illusion of a round star

The star’s gradient

Actually, it took quite some tweaking to get a nice gradient of white in the middle and yellow to red on the edge. It’s a basic Sprite gradient fill, using three colors, alpha layering and a specific color ratio array to get the last two colors (yellow and red) on the edge. Then I’m applying this gradient twice on the same canvas to get the result I want when the flaring corona’s are added. I couldn’t get it the way I wanted with the alpha array alone (let me know if you got a better way), but this worked and the gradients are only calculated and drawn once.

Drawing it twice means less transparency and that means more dense flares as we’ll see later on when we’re combining the star glow layer and corona layer using BlendMode.ADD (which is also the reason why we need MovieMaterial here: otherwise they won’t interact on layer-level).

// pseudo code
var sunColors:Array = [0xfefefe, 0xFAEB61, 0xff0000]; // white, orange/yellow, red
var sunAlphas:Array = [1, .8, 0]; // white part opaque, 20% from the edge out fading out
var sunRatios:Array = [0x85, 0xAA, 0xDD]; // all white except for the edges

var size:Number = 1000;
var sunglowMaterial:MovieMaterial = createSunglowMaterial(size, sunColors, sunAlphas, sunRatios);
var sun:Plane = new Plane(sunglowMaterial, size, size, null, null);

/**
 * Creates a disc texture using radial alpha. Draw twice for extra intensity of the colors.
 */
private function createSunglowMaterial(size:Number, colors:Array, alphas:Array, ratios:Array):MovieMaterial {
	var mat:Matrix = new Matrix();
	mat.createGradientBox(size, size);
	var sunTexture:Sprite = new Sprite();
	for (var i:Number = 0; i < 2; i++) {
		sunTexture.graphics.beginGradientFill(GradientType.RADIAL, colors, alphas, ratios, mat);
		sunTexture.graphics.drawRect(0, 0, size, size);
		sunTexture.graphics.endFill();
	}
	return new MovieMaterial(sunTexture, true);
}

The star's flaring corona

The corona was tricky. I needed to find some way to create a seamless and continuous outward motion of a Perlin noise map that would function as a flare animation. In the end I settled for a two plane solution where one slowly grows and finally fades out at which point the second fades in, rotated randomly and grows until it fades out again. Rinse and repeat. When calibrated carefully, the resizing, rotating and fading is imperceptible to the eye, due to the naturally distributed Perlin noise:

The Perlin noise is added with a simple Perlin noise command as follows:

var coronaMaterial1:BitmapMaterial = createCoronaMaterial(size / 1.25, size / 100, SEGMENTS);
var coronaMaterial2:BitmapMaterial = createCoronaMaterial(size / 1.25, size / 100, SEGMENTS);
var corona1:Plane = new Plane(coronaMaterial1);
var corona2:Plane = new Plane(coronaMaterial2);

/**
 * Creates a perlin noise texture to simulate the flaring flames on the sun's outer glow.
 */
private function createCoronaMaterial(textureSize:Number, noiseSize:Number, segments:Number):BitmapMaterial {
	var coronaBitmap:BitmapData = new BitmapData(textureSize, textureSize);
	coronaBitmap.perlinNoise(noiseSize, noiseSize, 4, 61, true, true, 1, false);
	return new BitmapMaterial(coronaBitmap, true);
}

The algorithm to animate the two planes is included in the attached sources.

The corona and star glow combined and masked by a perfect circle

The planes are all on the same depth and level. This works because we're using alpha ratios to determine where one plane's visibility starts and the other disappears. The star glow textures stands on its own, it is inherently radial and as such doesn't need a circle mask. This leaves the Perlin noise textures which need masking. To do this, I've put them in separate layers, which are then both masked by a third layer.

/*
 * use root corona layer so we can perform an alpha mask to both child layers at once
 *     - contains child corona layers so we can control individual alpha properties
 *         - contains child corona planes so we can apply a perlin noise texture to it for 'flaring' effect
 */
var coronaLayer:ViewportLayer = new ViewportLayer(viewport, null);
coronaChildLayer1 = new ViewportLayer(viewport, null);
coronaChildLayer2 = new ViewportLayer(viewport, null);
coronaLayer.addLayer(coronaChildLayer1);
coronaLayer.addLayer(coronaChildLayer2);
coronaChildLayer1.addDisplayObject3D(corona1);
coronaChildLayer2.addDisplayObject3D(corona2);
viewport.containerSprite.addLayer(coronaLayer);
// give the corona of the sun a 'flaring' effect
coronaLayer.blendMode = BlendMode.ADD;

// only show the corona part of the flaring perlin noise planes
var coronaMaskLayer:ViewportLayer = viewport.getChildLayer(coronaMask);
coronaLayer.cacheAsBitmap = true;
coronaMaskLayer.cacheAsBitmap = true;
coronaLayer.mask = coronaMaskLayer;

On a final note, I'm using the skybox from the skybox tutorial and also the RealtimeDisplayObject3D helper baseclass for the sun's scene updates (which is why the coronas keep animating smoothly even at low FPS).

trackback

Since Mass Effect is going to be a trilogy (and more apparently), Bioware included a system that will use old save games as input for continuity in upcoming games, including ME2. Note that you’ll still be able to pick a different face and class.

Get your Mass Effect 1 save games at masseffectsaves.com

I didn’t know there would be an option to use ME1 save games as input until recently and I’ve deleted my save games a long time ago. No undelete program would find them. Annakie recognized this would be a problem and started a small site that offers various save games each with a different set of key choices made over time in ME1.

How awesome is that!

Take your pick as the list is growing fast and the website is becoming a popular hub for Shepards.

trackback

Originally, this whole workaround came from a post on ubuntuforums.org by Unkie, which I modified only slightly (I’m plantface there). This workaround revolves around hidd, which was removed in Ubuntu 9.04 which you can get back as follows:

sudo apt-get install bluez-compat

Hidd is a tool that works like a charm for scanning and connecting to bluetooth devices. It’s still used these days because the Ubuntu dev team somehow manages to kill bluetooth support every new version. There are so many tutorials and flavors floating around to get a bluetooth device working and apparently with so little success that hidd remains popular. With 9.04 they gave bluetooth an overhaul and deprecated hidd.

Anyway, here’s the shell script that keeps connecting your keyboard. There’s one catch though: I haven’t figured out how to let the keyboard sleep, awake and reconnect itself, so you’ll need to hit the reset button on the keyboard to reveal itself to the bluetooth adapter looking for it. Reconnecting this way requires thus one extra manual action before it reconnects (same thing goes for when you rebooted). But it reconnects when you want it to, which is what I’m content with for the moment, considering the alternative.

1. First create a new file for the script:

   sudo nano /etc/keyboard.sh

   Add the following script:

   while (sleep 10)
   do
   sudo hidd --connect AA:BB:CC:DD:EE:FF > /dev/null
   done
   

   Close and save.

   Note: that AA:BB address should be the MAC address of your keyboard. You can find it using the new bluetooth tool hcitool scan (make sure your keyboard is findable by hitting its reset switch) or with hidd –search, which coincidently will automatically attempt to connect your device while scanning it.

2. Next we’ll make sure it’ll run in the background when booted. Create a new boot entry:

   sudo nano /etc/init.d/keyboard

   Add the following script:

   #!/bin/sh
   
   /etc/keyboard.sh &
   
   exit 0
   

   Close and save.

3. Give both files execution rights with chmod +x {filename}
4. Now run the following command:

   sudo update-rc.d keyboard defaults

Reboot and check if it works. Remember to hit your keyboard’s reset switch when you want Ubuntu to connect your keyboard.

trackback

Apparently, it has nothing to do with the source folder you see in the Project Explorer view, or the export settings in the Buildpath dialogs: instead you need to edit the Eclipse settings file “project-war\.settings\org.eclipse.wst.common.component” (viewable in the Navigator view) and modify the deployed source folders in there. Changes there do *not* reflect in the Project explorer (at least not with my version of Eclipse, Galileo). I’ve removed the test sourcefolder from there and everything was honky dory.

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
  <wb-module deploy-name="foo-war">
    <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/resources"/>
    <property name="context-root" value="foo"/>
    <property name="java-output-path"/>
  </wb-module>
</project-modules>

trackback

Make Eclipse ignore .svn directories

Window -> Preferences…, Java -> Compiler -> Building. Under “Output folder” add “, .svn/” to “Filtered Resources” (so that you get “*.launch, .svn/”).

It still works like a charm. Thanks Brian.

trackback

• download PagedList

Lazy loading with the PagedList

Originally I made the PagedList because I needed paged data fetching using JMS queues for a JSF Rich datatable and datascroller; a common problem in JSF but less commonly solved, even less documented and less still solved in an elegant way. Most people are able to solve this problem by using an OpenSessionInView antipattern (keeping Hibernate-oid session open until the view requests the lazy loaded data) but since I’m using JMS queue, this was not an option. I decided to circumvent the entire JSF to JMS queue integration by providing my data in a paging lazy list. It works beautifully.

public class PagedList<Dto, QueryParameters> extends AbstractList<Dto> {

    private final QueryParameters queryParameters;

    private final PagedDataProvider<Dto, QueryParameters> pagedDataProvider;

    private final Map<Integer, List<Dto>> fetchedPages;

    private final int dataSize;

    private final int pageSize;

    public PagedList(PagedDataProvider<Dto, QueryParameters> pagedDataProvider, QueryParameters queryParameters) {
        this.pagedDataProvider = pagedDataProvider;
        this.queryParameters = queryParameters;
        fetchedPages = new HashMap<Integer, List<Dto>>();
        dataSize = pagedDataProvider.getDataSize();
        pageSize = pagedDataProvider.getPageSize();
    }

    public Dto get(int index) {
        int pageNr = (int) Math.floor(index / pageSize);
        if (fetchedPages.get(pageNr) == null) {
            fetchedPages.put(pageNr, pagedDataProvider.provide(pageNr, queryParameters));
        }
        return fetchedPages.get(pageNr).get(index % pageSize);
    }

    public int size() {
        return dataSize;
    }
}

It is different from Apache’s LazyList (and many other implementations) in that it relies on an external dataprovider to provide the dataset’s total size, pagesize and data provision itself. For example, using my lazy list version the size() method actually returns the total size of data potentially available, not just physically available in the list at the present. This way the list works completely transparent to its users. Also, there is no simple factory being passed in that creates dummy objects or something: actual remote data is being fecthed in pages by a data provider. Pages being fetched are independent of each other; when requesting page 5, page 1 through 4 are not need or fetched.

The PagedList works in combo with a PagedDataProvider interface that external dataproviders (some dao for example) could implement. So it has no dependencies whatsoever on some specific implementation. The paged data provider provides the total size of the dataset, the page size and pages of the dataset itself when needed.

Example implementation for JSF and JPA dao

Here’s an example implementation which ties a JSF Richfaces datatable to a JPA dao using a PagedList. I cut out the service layer, view handlers/controllers and whatnot for sake of simplicity.

<rich:dataTable id="searchResults" value="#{appleService.apples}" var="apple">
...
</rich:dataTable>

/**
 * JPA dao which acts as paged data provider for the paged list.
 *
 * Relies on two JPA named queries specified on the Entity being fetched.
 *
 * @author Benny Bottema
 * @see PagedDataProvider
 */
public class AppleJPADao implements AppleDao, PagedDataProvider<AppleDto, AppleQueryParameters> {

    // entitymanager stuff omitted for example (real world: injected by Spring)

    private static final int PAGESIZE = 50;

    /**
     * @see AppleDao#getAllApples(String, String)
     */
    public List<AppleDto> getAllApples(String type, String quality) {
        // optional query parameters: can be null
        AppleQueryParameters params = new AppleQueryParameters();
        params.setAppleType(type);
        params.setAppleQuality(quality);
        return new PagedList<AppleDto, AppleQueryParameters>(this, params);
    }

    /**
     * @see PagedDataProvider#provide(int, Object)
     */
    public List<AppleDto> provide(int page, AppleQueryParameters queryCriteria) {
        Query query = entityManager.createNamedQuery("Apple.findAll");
        query.setParameter("appleType", queryCriteria.getAppleType());
        query.setParameter("appleQuality", queryCriteria.getAppleQuality());
        // JPA's paging mechanism
        query.setFirstResult(PAGESIZE * page);
        query.setMaxResults(PAGESIZE);
        return (List<AppleDto>) query.getResultList();
    }

    /**
     * @see PagedDataProvider#getDataSize()
     */
    public int getDataSize() {
        Query countQuery = entityManager.createNamedQuery("Apple.count");
        return ((Long) countQuery.getSingleResult()).intValue();
    }

    /**
     * @see PagedDataProvider#provide()
     */
    public int getPageSize() {
        return PAGESIZE;
    }
}

Known issues

So far there is only one known issue, which is more of a problem with lazy loading in general: synchronizing the lazy loading list with the remote dataset to avoid becoming stale when changes happen to the dataset. Example: when the dataset changes, the size of the list is not being updated and the get() method may try to fetch wrong or even unavailable data throwing an exception. Since I’m using the paged list in a limited way, I’ve not yet encountered this problem.

One way would be to solve this problem for the Rich datable and datascroller specifically is to have a a4j poll component that listens for dataset changes on the server and refreshes the entire datatable as necessary. Just thinking out loud here…

trackback

I had to tone down the size and fps, and leave out the bumpmap for this demo because my Opera browser was halting when I added the other images and clouds swf demo :P

(notice the dynamic clouds and the glow around the globe)

• Download Clouded planet Earth source

On my core 2 duo laptop I get about 20-25 fps whith a slightly larger stage size and the movie set to 30 fps. Although the planet looks very nice to me, I also realize it isn’t very practical for games or other realtime simulations. To get better fps, you can remove the bumpmap texture, replace the realtime clouds with a fixed texture, user fewer segments in the spheres, zoom out more, or use lower resolution textures for land- and cloud materials. A combination of two or more of these suggestions should easily get you above 35 fps.

Used Ingredients

I’ll get into the explanations later, but here are the ingredients used in this example:

- A sphere for geological data (land texture)
- Another sphere for clouds
- two planes that mask a perfect circle for the spheres
- a plane that contains the fresnell glow on top

On the spheres I’ve used two phongshaded materials of which one has the land texture with a bumpmap for mountains and stuff, and the other contains the clouds texture with a runtime maintained perlin noise map applied to the alpha channel.

On the masking planes I’ve used a simple gradient circle shaped fill on the alpha channel.

On the glow plane I’ve used a gradient circle fill with a blue color and alpha channel for nice fading.

There’s also a pointlight in there that represents the sun (hits earth top-right).

Main textures

Earth surface

I took the public Earth surface texture (Blue Marble) from NASA, which I used on the sphere. On the rightside you can see it applied to the sphere with phongshader.

The shown image is about the half of the size I used for the used texture. One thing I’ve noticed is how large the texture needs to be to get some decent quality when applied to a sphere. Maybe there’s some room for optimization there…

Clouds surface

For the clouds I initially started with the public clouds texture from NASA, but when I applied the dynamic visibility map it turned out I didn’t get enough cloud coverage, because in effect now two visibly maps were applied: nature’s own, hardcoded in the texture, and my own applied in runtime.

So I ended up mirroring the original clouds texture in both dimensions to get much more cloud coverage, so that when I apply my own runtime visibility map I get about as much cloud coverage as in the original image. When applied to the sphere, it is also subject to the Phong shader I’ve used.

 

I’ve increased overall brightness to get more out of the less dense clouds, but I’ve also increased contrast to get the clear shapes of the clouds. Then I’ve applied the image itself as its own alpha channel and played around with its visibility until it became what you see above.

For the runtime visibility map I’ve used the ever amazing perlin noise effect. Since perlin noise works with a phase, I can use that to animate perlin noise and apply the results to the alpha channel of the clouds texture. On a straight texture, it looks like the following example:

(click to see in action)

You can probably imagine how hard this must be to render each frame: a large clouds texture with alpha channel modified each frame by a new perlin noise map, with a phong shader applied. I see how this won’t work in a game, so I’ll probably use a fixed clouds texture in the future, but right now I’m satisfied with the effect.

Code walkthrough

Aside from the actual structuring of the code and Papervision3D usage, there are some interesting aspects to this demo. For example, there’s the Earth’s light glow, and the use of masking discs to disguise the low quality of the spheres. I’ve explained everything in details on this on the following page:

• Read the Earth code walkthrough

If anyone has suggestion on how to improve performance, please let me know!

trackback

• RealtimeDisplayObject3D.as

I use the convention of adding update methods to all (my own) DisplayObject3D objects, which then update themselves according to preconfigured settings (eg. passed in the constructor). I pass in a Camera3D and that’s it, let the objects do their own thing. I’m making use of this convention by extracting this update method to a baseclass which then can do time-based updates instead.

It only works for new classes you create that normally would extend DisplayObject3D, such as a composite parent DisplayObject3D. For example, if you were to create an Earth object in PV3D, you could create a new DisplayObject3D container class which adds a planet, clouds and a glow to itself as child objects. This Earth object could then extend our special class, RealtimeDisplayObject3D, for controlling time-based updates.

public class Planet extends RealtimeDisplayObject3D {

	private var earth:DisplayObject3D;

	// define: 1 update every 200ms (5 updates per second) and process 1 value per second
	public function Planet() {
		super(200, 1);
		// add planet, clouds and glow etc.
	}

	// rotates Earth 5 times per second, with a stepsize of 0.2 (1 second / updates per second)
	protected override function realtimeUpdate(camera:Camera3D, stepsize:Number):void {
		earth.rotate(stepsize);
	}
}

With the planet now extending our RealtimeDisplayObject3D class instead of DisplayObject3D, you can provide realistic rotation speed that is not influenced by the FPS the movie is pulling. Instead, it works by applying a set value-per-second (phase speed) and a required update frequency per second; the phase speed is spread out over the number of updates per second.

There is one requirement though: the fps the movie is pulling cannot go below the updates per second specified, or the updates per second is capped by the frames per second. If you specify 200ms for each update, this means 5 updates per second (1000 / 200). This won’t be a problem. If however you define 50ms for each update, this means 20 updates per second (1000 / 50). You must ensure that your movie is running on 20 frames per second or more.

Combining time-based updates with frame-based updates

You can still update normally on frame-based timetable by overriding the update(camera) method of the baseclass. Or, you can combine both type of updates by overriding update(camera), do a frame-based update, call super.update(camera) and override the realtimeUpdate(camera) method as we did before. Here’s an example of that:

public class Planet extends RealtimeDisplayObject3D {

	private var earth:DisplayObject3D;

	// define: 1 update every 200ms (5 updates per second) and process 1 value per second
	public function Planet() {
		super(200, 1);
		// add planet, clouds and glow etc.
	}

	// makes the planet face the camera each and every frame
	protected override function update(camera:Camera3D, stepsize:Number):void {
		earth.lookAt(camera);
		super.update(camera);
	}

	// rotates Earth 5 times per second, with a stepsize of 0.2 (1 second / updates per second)
	protected override function realtimeUpdate(camera:Camera3D, stepsize:Number):void {
		earth.rotate(stepsize);
	}
}

trackback

Here’s how you can do that in Papervision3D, using ParticleFields. I’ve used the trunk of the papervision code repository, revision 851, but it should work with the last release without to much hassle. Note that I’m no PV3D guru; I just started to learn this stuff and I’m just sharing what I’ve learned so far.

Here’s how it works:
• divide space into a 3d grid and parts of the spacedust cloud on 8 gridpoints directly around the camera (the ship), we’ll call these dustpockets
• when the camera moves, dustpockets are removed and created to keep only the 8 gridpoints around the ship occupied

Divide space into a 3d grid and snap dust pockets on it

We’re not actually creating a grid, but we’re going to say things like: “Give me the closest 3d point behind the ship in the upper left corner on the invisible grid”, so that we can create a dust pocket in that position. Sounds complicated? Luckily, the math is easy:

Let’s say there’s only the x-axis. Now from 0 to 100, I want the gridpoint on the left of 32 on grid with size 5. Here is how it would look:

As you can see, the x-value 30 is the value to the left of 32 on a grid with size 5. Here’s the equation to get to that answer:

gridpoint left: Xgrid = Xvalue - (Xvalue % gridsize)
gridpoint right: Xgrid = Xvalue - (Xvalue % gridsize) + gridsize

Example gridpoint left for value 32 and grid size 5:
gridpoint left: Xgrid = 32 - (32 % 5)
gridpoint left: Xgrid = 32 - (2)
gridpoint left: Xgrid = 30

Example gridpoint right for value 32 and grid size 5:
gridpoint left: Xgrid = 32 - (32 % 5) + 5
gridpoint left: Xgrid = 32 - (2) + 5
gridpoint left: Xgrid = 35

We’re going to apply this kind of math to find all 8 gridpoints around the camera. So not just the x-axis, but y and z-axis as well.

The reason we need these 8 gridpoints is because we can’t just create a single cloud. Since the ship can move in any direction and look in any direction, but we can’t fill all of space with dust particles due to memory restrictions, we need to dynamically ‘move’ the cloud with the ship, while keeping the dust particles on the same place. The only way to do this is by dividing the single dust cloud into several small ones and create them as the ship goes. At the same time we need to keep the number of particles down, so we need the minimum dust pockets and still cover all sides by create 8 small clouds that together form a big cloud and can grow in any direction without draining too much memory and cpu power.

Here’s how we’re going to place the clouds:

Here’s the code to do this:

public function update(fieldsize:Number = 2500):void {
	// calculate segment (dustpocket) size
	const FIELDSIZE_POCKET:Number = fieldsize / 5;

	// determine the 8 gridpositions around the ship (eg. 1: front bottom left, 2: behind top right)
	const pocketPositions:Array = new Array();
	pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, false, false, false));
	pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, true, false, false));
	pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, false, true, false));
	pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, false, false, true));
	pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, true, true, false));
	pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, true, false, true));
	pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, false, true, true));
	pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, true, true, true));
}

/**
 * Calculates a gridpoint around the ship.
 */
private function calcGridPosition(position:Number3D, gridSize:Number, xMin:Boolean, yMin:Boolean, zMin:Boolean):Number3D {
	const gridPosition:Number3D = new Number3D();
	gridPosition.x = (position.x - (position.x % gridSize)) + ((xMin) ? 0 : gridSize);
	gridPosition.y = (position.y - (position.y % gridSize)) + ((yMin) ? 0 : gridSize);
	gridPosition.z = (position.z - (position.z % gridSize)) + ((zMin) ? 0 : gridSize);
	return gridPosition;
}

This is really all there is to it. The only thing we need to do now is create new dust pockets for gridpoints without one and remove dust pockets for points that are not within range anymore. Over and over again. Here’s the entire Spacedust class:

package org.codemonkey.spacedusttutorial.papervision3d {
	import flash.utils.Dictionary;
	import org.papervision3d.cameras.Camera3D;
	import org.papervision3d.core.math.Number3D;
	import org.papervision3d.materials.special.ParticleMaterial;
	import org.papervision3d.objects.special.ParticleField;
	import org.papervision3d.scenes.Scene3D;

	/**
	 * Spacedust simulator. Creates 8 segments of the dustcloud around the given camera at any point in space.
	 * When the camera moves, new dustpockets are generated and old ones (out of sight) are removed.
	 *
	 * @author Benny Bottema
	 */
	public class Spacedust {

		private static const DEFAULT_PARTICLEMATERIAL:ParticleMaterial = new ParticleMaterial(0xffffff, .5, ParticleMaterial.SHAPE_CIRCLE);

		private var basic3DSetup:Basic3DSetup;
		private var camera:Camera3D;
		private var spacedustCloud:Dictionary;

		private var fieldsize:Number;
		private var particleCount:Number;
		private var dustMaterial:ParticleMaterial = new ParticleMaterial(0xffffff, .5, ParticleMaterial.SHAPE_CIRCLE);

		public function Spacedust(basic3DSetup:Basic3DSetup, camera:Camera3D = null, fieldsize:Number = 2500, particleCount:Number = 400, dustMaterial:ParticleMaterial = null) {
			spacedustCloud = new Dictionary();
			this.basic3DSetup = basic3DSetup;
			this.camera = (camera != null) ? camera : basic3DSetup.camera;
			this.fieldsize = fieldsize;
			this.particleCount = particleCount;
			this.dustMaterial = (dustMaterial != null) ? dustMaterial : DEFAULT_PARTICLEMATERIAL;
		}

		public function update():void {
			// calculate segment (dustpocket) size
			const FIELDSIZE_POCKET:Number = fieldsize / 5;

			// determine the 8 gridpositions around the ship (eg. 1: front bottom left, 2: behind top right)
			var pocketPositions:Array = new Array();
			pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, false, false, false));
			pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, true, false, false));
			pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, false, true, false));
			pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, false, false, true));
			pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, true, true, false));
			pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, true, false, true));
			pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, false, true, true));
			pocketPositions.push(calcGridPosition(camera.position, FIELDSIZE_POCKET, true, true, true));

			var newSpacedustCloud:Dictionary = new Dictionary();

			// create new dustfields or transfer existing ones (and remove existing ones the scene)
			const particlesPerPocket:Number = particleCount / pocketPositions.length;
			for each (var pocketPosition:Number3D in pocketPositions) {
				var pocketKey:String = pocketPosition.toString();
				var reusableDustPocket:ParticleField = spacedustCloud[pocketKey];
				// remove so we can delete the particles from the remaining particlefields (which means they are out of sight)
				delete spacedustCloud[pocketKey];
				// add the removed particlefield to the new dustcloud or create one if dustpocket is new for te current gridposition around the ship
				if (reusableDustPocket != null) {
					basic3DSetup.removeFromScene(reusableDustPocket);
					newSpacedustCloud[pocketKey] = reusableDustPocket;
				} else {
					newSpacedustCloud[pocketKey] = new ParticleField(dustMaterial, particlesPerPocket, 2, fieldsize, fieldsize, fieldsize);
					newSpacedustCloud[pocketKey].x = pocketPosition.x;
					newSpacedustCloud[pocketKey].y = pocketPosition.y;
					newSpacedustCloud[pocketKey].z = pocketPosition.z;
				}
			}

			// manually remove all the remaining obsolete particles from the old cloud (they are out of sight)
			for each (var oldDustPocket:ParticleField in spacedustCloud) {
				oldDustPocket.removeAllParticles();
			}

			// now add the old dustpockets which are still within sight, plus the new dustpockets to the scene
			for each (var newDustPocket:ParticleField in newSpacedustCloud) {
				basic3DSetup.addToScene(newDustPocket);
			}

			// replace the old cloud with the new cloud
			spacedustCloud = newSpacedustCloud;
		}

		/**
		 * Calculates a gridpoint around the ship.
		 */
		private function calcGridPosition(position:Number3D, gridSize:Number, xMin:Boolean, yMin:Boolean, zMin:Boolean):Number3D {
			const gridPosition:Number3D = new Number3D();
			gridPosition.x = (position.x - (position.x % gridSize)) + ((xMin) ? 0 : gridSize);
			gridPosition.y = (position.y - (position.y % gridSize)) + ((yMin) ? 0 : gridSize);
			gridPosition.z = (position.z - (position.z % gridSize)) + ((zMin) ? 0 : gridSize);
			return gridPosition;
		}
	}
}

• Download Spacedust.as
• download entire spacedust source

Notice the particel fields we’re using to create the eight dust pockets with.

new ParticleField(dustMaterial, particlesPerPocket, 2, fieldsize, fieldsize, fieldsize);

Also, the Basic3DSetup class I’ve used is simply a convenience class with default camera, scene, viewport etc. It’s much like Papervision’s own BasicView -which I didn’t know about at the time- except even cleaner.

The Spacedust class accepts an optional camera to position the dust cloud around. Since this approach is meant to create the illusion of infinite space dust, it doesn’t make sense to create clouds on non-camera’s. Also, you can specify your own particle count and dust material in the constructor of the Spacedust class. The example at the top of the page uses only the defaults.

trackback

[RE: JSF – Still pretty much a steaming pile of donkey turd] – I was replying to Wille Faler’s post about why JSF sucks, when the comment was getting too large, so I made it into a post on my own blog.

JSF is hard to learn yes, but in my opinion it doesn’t suck as bad as Wille says. All the points Wille mentions can be solved by certain libraries or write-once reusable solutions (I’ve included my ‘magical’ combination of frameworks on the bottom). JSF is a diamond in the rough, you just need to make it shine.

The devil is in the details

There are a couple of pitfalls you need to know about with JSF. It’s all really a matter of having read a good book about JSF that points them out, or having learned them the hard way. Luckily I’ve had some guidance by experienced colleagues of mine; I’m guessing that’s the missing factor in Wille’s situation.

Referring to the pitfalls you need to know about, I’m talking about the common beginner’s problems like using JSTL c:tags that cause havoc when combined with those of jsf and facelets. I’m talking about the Ajax4Jsf details as Wille mentioned: once you know what to use it’s easy. Those 48 attributes? most of them are inherited and never used and you can forget about them, and that’s the learning curve. Once you know the right ones, it’s using exactly those, over and over again. And things like how you can incorporate Spring security and stuff like that. Another pitfall that comes to mind is how action=”" work quirky with navigation rules when using the array notation (action=”controller['action']“). And ofcourse there’s the issue of parameterized JSF validators, which needs some understanding. All pitfalls that can baffle a beginner or intermediate.

The thing with JSF is there are a number of little things that are hard to solve, but once you’re past that it does make you much more productive. You just have to have a solid base to start from each project. The pitfalls learning curve is definitely a downside of JSF, but JSF 2.0 is in the making to solve all these issues.

Bad performance or beginner’s mistake?

Then there is this performance issue Wille mentions, where I think he missed the target: JSF does not have to be slow at all. It really depends on how you treat your backing beans. JSF has the weird tendency to call setters/getters multiple times, which seems utterly pointless (it’s related to resolving valuebindings in nested components). I’ve made the mistake before to directly retrieve values from a controller/service in my views instead of a static model (backing bean): this is what makes things slow. JSF in itself isn’t that slow for a webapp: yes there are many redundant calls but we’re not dealing with a realtime simulation application, webapps do just fine. On a sidenote, it also depends on the implementation… JSF is a reference specification, while there are various implementations of the framework (IBM’s, Sun’s etc.)

SEO friendly JSF?

Ahh, but for the JSF Search Engine Friendliness. That’s solved too, somewhat. There’s is a framework called PrettyFaces which allows you to dynamically generate/interpret pretty GET urls with bean values. It’s a great framework that solves a common problem, but there still exists the problem that existing jsf/facelets/richfaces components are not generating SEO HTML code. That’s really the fault of the component makers, not JSF, though JSF definitely isn’t innocent with its POST obsession: PrettyFaces fixes at least that.

Common sense: use frameworks to avoid most pitfalls

Once you’ve got those kind of things down and use a good framework combo, JSF is straightforward. You won’t really need to know about the various phases and you can be very productive if you’ve set up the jsf/facelets components right. I’ve worked with JSF intensively for about a year now in various projects with various implementations and I hardly ever need to use phaselisteners and that sort of stuff. The rare cases where you do need them, you can define these things ones and reuse them in other projects. With this approach I’ve created a template project with some standard libraries, phaselisteners, security set up, facelets components etc. and I’m up and running in no time.

I haven’t sanitized or otherwise cleaned up the template project so I won’t put that up for the time being, but at least I can tell you what frameworks are in it by default.

The magical combination that works for me and my colleagues:
• JSF (MVC)
• Facelets (Templating, use of XHTML)
• Richfaces (component suite)
• Richfaces A4J (Ajax support)
• Tomahawk (only for file uploads with the Extensions Filter)
• PrettyFaces (for indexable GET urls)

Now that I’ve mentioned these, you should check out JBoss Seam as well, which basically is supposed to do everything the above libraries do combined, plus a couple of things more like solving the conversational scope issue. I haven’t worked with this framework myself though so I can’t speak from experience.

Final note

Although I agree JSF has some annoying pitfalls, shortcomings and a high learning curve, it’s been out there for enough time to pass for supplement frameworks to pop up from under the ground to solve most of these problems.

With the right combination, most classic counter arguments have become obsolete. Maybe it’s time for critics to take JSF as is: incomplete but ultimately making you more productive if combined with the right frameworks.

trackback