[Generic Java Importer]

You could maybe also test the load time of the FileLoader object. But I think 8 seconds parsing time is okay, if it takes 4 on desktop.

Anyway, I updated the library. As promised, you are now able to use character maps. Implementation was easier than I thought ;).

Character maps can be assigned to any SpriterAbstractPlayer class.

There are two possibilities to assign a character map to a player object:

//1. version just assign a character map to the public field in SpriterAbstractPlayer
player.characterMap = yourCharacterMap;
//2. if your player is a SpriterPlayer instance, just use the setCharacterMap() method
player.setCharacterMap("nameOfYourCharacterMap");

To get a character map, you need an entity from the loaded SpriterData instance and then get a map either via index or by name:

yourSpriterInstance.spriterData.getEntity().get(0).getCharacterMapByName(name);
//or
yourSpriterInstance.spriterData.getEntity().get(0).getCharacterMaps().get(charMapIndex);

The characterMap field of a player instance can be null to behave like Spriter if no map is applied.

If any bugs occur please let me know it, otherwise: Have fun with it!

-Trixt0r

[Generic Java Importer]

20 sec seems to be very long. How big is this scml file?

The parser was not written by me. I just took the xml parser libgdx has and replaced the collection objects.

- Trixt0r

[Generic Java Importer]

Do you have an estimate for the character maps implementation at all?

I could try to implement character maps until the next weekend. I see no chance for me to work on it sooner.

There are many of us in the libgdx community who anxiously await your reply.

:D really? Well, I will try my best to implement the new features asap.

- Trixt0r

[Generic Java Importer]

Ok, I looked into my current version and saw that I already fixed the nullpointer thingy, but did not push it.

The alpha issue is also fixed.

Just pull the new version.

Thank you guys for detecting such bugs.

I will work on the new interplation stuff and character maps as soon as possible.

- Trixt0r

[Generic Java Importer]

Sorry guys, for not responding to your questions. I am quite busy now.

@Aniketos: The ref is null in the first place, because the loader is putting a null reference into the texture map and in a next step the actual loaded file reference will replace the the null reference. Are you loading will multiple threads?

@kabb: This is really weird. It should work. Could you send me your whole code?

- Trixt0r

[Dynamic Lighting with Spriter animations]

As I said, the image was generated with a photorealistic lighting model, where intensity of lights can be parameterized, and not a cel shader.

Btw, you can not overexpose a surface from a scientific point of view, white is white.

- Trixt0r

[Dynamic Lighting with Spriter animations]

Hey guys.

I implemented a little command line tool with Java which is able to create a normal map from two given textures which represent a sprite lit from the right and from above.

In the zip file are two executable jar files which work slightly different. normalsGeneratorTwo.jar uses the mathematical right algorithm to create the normals but the other jar produces a better solution in my opinion.

To run it you should update your Java runtime environment to 1.7. Call the tool from the command line (on Windows from cmd.exe, on Unix from the console).

The usage is:

java -jar normalsGenerator.jar nameOfTheHorizontalLitTexture.png nameOfTheVerticalLitTexture.png outPutName.png

The last argument is optional, if it is not given the tool will create a file named "normalMap.png".

Edit: tombonkey, yeah sounds good. I have to do some other works for university in the next weeks (until Christmas) but I will try to test it if I have time.

Edit2: Added file, sorry :D

- Trixt0r

normalGenerators.zip

[Dynamic Lighting with Spriter animations]

But would that work when dynamically reordering parts? - Would that require dynamic z-values, or could we use the z-order to correct this?

Yes it should work. I do not know what you mean by "could we use the z-order to correct this", but it would work with the z order you use in Spriter. How far the z index 0 is away from z index 10 depends on the engine itself. I would just use a factor to control those z indices and distances. For your example let's say the nose is on z index 5 (above the face) and the faces has a z index 1. The distance between the z values should be then:

zDistance = (nose_index - face_index)*factor

let's say factor is 0.01 (how big this factor is depends on your camera properties, etc.) then you get a distance of 0.04, and the face has a z value of 0.01 and the nose 0.05. The distance can be taken e.g. for some shadow mapping (if the distance is bigger than 0.06 do not apply shadow mapping or something like that...) and the z value itself is lateron useful for your lighting, e.g. for illuminating only sprites in the background, etc..

On that note...would the light be applied on each part separately or on a pre-constructed character. Yes, I know this doesn't matter from an artistic point of view, but it does matter...

This depens heavily on the engine, you use. Because if your engine uses forward light rendering, every light calculation is applied to each sprite. If you use deferred light rendering the illumination stuff has to be calculated from a geometry buffer (a group of different textures your engine renders to) which contains all the information (positions, colors, normals, etc.) you need to make the lighting happen. And this g-buffer contains your whole scene you can currently see, i.e. all your characters which get animated (or anything else that can be drawn). The drawing happens then in 2 steps: render to the g-buffer and then render the illumination stuff to the screen with the g-buffer.

I hope this clearifies some things :D

Edit: The guy who made the cel shading with the ryu sprite posted a link to the resources. Looks like he is using a similar technique Sprite Lamp is using. For those who are interested in how the lighting would look like with a non cel shader, i.e. lambert shader:

I think it looks good, much more 3d-ish, but the cel shader fits better to the art style (I am using the same normal map the dude is using in his video, so the lighting has nothing to do with the normal map itself).

- Trixt0r

[Dynamic Lighting with Spriter animations]

[...] but it does feel a bit computer generated [...]

Of course because those maps are computer generated :D. No one has time to make normal maps by hand.

[...] I think 'simple' rim lighting would suffice [...]

Yeah, I am using such a rimlight technique in my current LibGDX engine inspired by this post (sorry for reposting my videos...).

I do wonder how best implement normal maps with modular animation. Simple use-case: I have a nose on my face. The nose is a separate object (for whichever reason). How would I ensure that a. the heights of the nose and the face match up, and b. how would I make modules cast shadows upon other modules (nose on face)? - Otherwise the perceived depth might break the illusion.

For a.: It is quite easy if you think in 3D (because every common lighting model works with 3 dimensions, it does not matter how many dimensions (2 or 3) your rendering engine is using). Give your nose and your face different z values and the rest will be done by the illumination model in your engine.

For b.: Casting/mapping shadows is engine related and as an artist I would not worry about the implementation stuff (I did not implement it yet, but I think it is not that hard).

Maybe next year when sprite lamp is out we can make a small game to show off this tech with spriter in a more complete way.

I am ready for it. ;D

That ryu looks better but hes not moving so its easier[...]

It makes nothing easier. You still have to create a normal map for that sprite and the effort is similar to the one you have if you would use sprites which are composed of different bodyparts. And the effort gets equal if you use a texture atlas for all your bodyparts.

I do not understand why you guys worry about dynamic/realistic lighting combined with bone based sprite animations? If you have well fitting normal maps the resulting visual effects will please you as hell :D. Maybe I underestimate the workload for creating normal maps by hand, but to solve this problem: Sprite Lamp is coming... I am looking forward to this peace of software.

- Trixt0r

[Dynamic Lighting with Spriter animations]

I didn't know normal maps required alphas

Sorry that I did not notice you about that. In general normal maps do not require an alpha channel. But if you make animations with Spriter and sprites which have an alpha channel you do not see (or do not care about) how the rectangle of your sprite overlaps with another sprite which is drawn below. Now if you draw the same normal sprites to your normal buffer in your engine and your alpha channel was not preserved when generating the maps your resulting image on the normal buffer will look different than the color/diffuse buffer because now you have some blue-ish color values (i.e. the z-value of the surface normal) where some transparency should be.

Ok, I made a little rotation test for the head with your normal map, tombmonkey:

Looks much better than mine. :D

I think it should be done differently, similar to rayman legends, so if theres lihgting then it reveals second map and blends between lit and unlit body part.

I do not get what you mean. Rayman Legends uses standard illumination models with some more advanced techniques (area lighting, etc.). I would not discuss about those things here.

This thread is meant to be a place to discuss about illumination and cut off animations in general. What Ubisoft's engine is doing in Rayman goes beyond this whole stuff.

not sure how to implement this in a construct 2 platformer environment, any tips would be greatly appreciated

I started with this little example. If you get how the vector calculations work, you can go further and involve an angle into your shader program and rotate the vectors from the normal map. It is very simple compared to the normal mapping in a "real" 3D space, where you have to calculate tangentspace matrices and stuff.

Edit: Using proper normal maps can lead to very very nice visual effects:

- Trixt0r

[Please post feature suggestions here.]

Here you go, guys. Post anything related to the shading stuff in that thread.

[Dynamic Lighting with Spriter animations]

Hey guys,

I created this thread to let you discuss about the here mentioned topic, since this is not really Spriter feature related.

Anyway, I tested the shading stuff with Spriter and pre rendered/generated normal maps. I used tombmonkey's flower girl for the tests (sorry tombmonkey, but the ZIP file, you provided, has not normal maps for every sprite. In addition your program (Crazy Bump, I think?) removed the alpha channel for the normal map, which would end up in some very ugly rendering. So I had to create my own with ShaderMap 2. But those which you uploaded are much better and smoother than mine. Maybe you could add the remaining if you've got time.)

And here you have some screenshots:

First of all the scene without shading:

And here is the same scene with some lights and a dark environment:

As you can see it does not look very good because the character was not designed for dynamic light rendering and the normal maps are really shitty.

It looks like an emboss effect.

What do you think?

Maybe we could create some other scenes with different art styles and proper normal maps.

- Trixt0r

[Please post feature suggestions here.]

hey tombmonkey,

yes of course, it is usual normal/bump mapping as you would use in a 3d environment (of course simplified since you drop one dimension). If your engine uses a proper bump map implementation, you should not worry about illumination issues.

But you may get some smoothness issues between every body part (too sharp edges, falloff issues, etc.), depending on your art style (if you have sharp edges for each body part those issues will not occur, I think). This can be bypassed with the new skinning feature of Spriter, i.e. instead of creating e.g. three sprites for the arm (upper, lower, hand), you create just one sprite for the whole arm, split it in to three skin parts and attach a bone to each part. Of course the engine, you are using, has to support the skinning feature.

If you could send me some normal maps for your flower/gras girl, I could create another demo video to show you guys how dynamic lighting would look like with bump maps per bodypart.

I may also write a simple application which has the ability to load an SCML file, link the corresponding normal maps to the sprites and illuminate animations with those normal maps. This would remove unnecessary work for future Spriter builds (since this topic has absolutely nothing to do with animations).

I think this was enough off topic for this thread :D.

- Trixt0r

[Please post feature suggestions here.]

[...] it would need to detect rotation and switch slowly for example from top to right side during body rotation.

No, you just need to rotate the normal vector of the bumpmap.

[Please post feature suggestions here.]

I do not know, if this was already mentioned, but if the skinning feature would provide more control over the bending curves between two bones, animations could be created much easier. The current fiddling is very suboptimal.

It doesnt look nice on sprites ingame, looks like bump mapped sprites, unless someone likes bump mapped sprites, its 4 additional lighting maps per one frame, thats totally not worth it imo.

So you want to tell us, that the left, unshaded sprite looks better than the right one?

It is completely worth it and you do not need 4 maps. 2 are enough and with some extra programming effort you only need one additional texture for each sprite. Anyway, my example does not rely on any extra bump map, everything is calculated on the fly and it took me not much time to create this picture.

I also do not think, that Spriter has to cooperate with Sprite Lamp since dynamic lighting is only engine based and has nothing to do with the animations. Creating normal maps is a seperate task and very time consuming. But it would be useful if Spriter had the ability to switch between diffuse and normal maps (or any other corresponding information containing texture) while creating animations. Something similar to character maps?

Edit:

Here is an example how it would look like, if you would use dynamic lighting with Spriter:

-Trixt0r

[Spriter B6 pre-release ready for Windows testers]

Hey Edgar!

Very nice stuff, you implemented in Spriter B6.

How do you calculate the bending curves for skins when they get applied to bones? Looks like this also based on Beziér curves?

Would be nice if you could post some pseudo code for the API guys. Then I could try to implement that feature in the Generic Java API.

Keep up the good work!

-Trixt0r

[Generic Java Importer]

Thanks for the bug report, HipGnose!

This is of course a bug. Seems like I was fully retarded when writing this method.

It will be fixed with the next commit.

Discobeard, I have to thank you! Without your basecode I would not have started working on a Spriter API.

It would be cool, if you could update the LWJGL and Slick2D examples with every major update, since I am very busy with the LibGDX stuff.

Threaded resource loading support would be cool.

- Trixt0r

[Generic Java Importer]

Thanks for finding this out, arnelpogs!

I pushed some changes in the libGDX loader.

The loader now should not have any problems with different OpenGL ES versions. So you are also able to use version 1.0 if you like. And of course I added the iOS thingy to it. In addition, instead of being silent, the loader throws a gdx runtime exception if the file is not found to see what is actually going on.

Edit: I also copied the examples for LWJGL and Slick2D from Discobeard.

- Trixt0r

[Generic Java Importer]

Could you tell me on which device (and on which iOS version) you are testing the code?

- Trixt0r

[Generic Java Importer]

Hi arnelpogs,

I'm very sorry for the problems which are occuring on iOS, but I can not test my code on such a device since I have no apple products.

Thank you for the message. I do not have any clue how RoboVM compiles the Java code and I saw that there are several limitations if you are using RoboVM to get Java code working on iOS. Anyway, could you please tell me what your approaches were to fix the issue? Can you post some code?

Seems like there is something wrong when loading the Sprites and posting Runnables to the LibGDX rendering thread. Try to comment the postRunnable thingy out and load everything on the rendering thread, like I described here. That is the only thing I can think of, when looking on the stack trace. Are you already using FileHandleSCMLReader?

Maybe I should mention one thing:

The loader class for the LibGDX example is capable for loading the sprites asynchronously to the LibGDX main thread and I only tested this on desktop/laptop. So if you do not need to load your spriter resources in another thread, please remove the

Gdx.app.postRunnable(...);

stuff in the loader. Especially if you want to use the library on mobile devices with just one thread/porcessor or in the browser.

If you initialize a SpriterPlayer object you have to make sure that every reference (i.e sprite) has been loaded, otherwise you will get such a NullpointerException because the generateData method relies on the fact that every reference is already mapped to a specific texture object. Perhaps I should add something like a LoaderListener which gets notified if the loader has loaded all necessary sprites.

I the meantime you could just iterate through the files map and check if the mapped object is null or not and if no null value occured create the player. Or just wait some time/steps before creating a player (e.g. 60 steps or 1 second).

Sorry for no update for the last 2 months. I am currently working on my bachelor thesis about deferred rendering and have not that much time to update the library. But I am definitely going to implement more stuff, especially the free-form stuff which has been added in the B6 version and of course the character mapping and the qudratic, cubic and bezier tweening. Don't worry about that. My private projects rely on such features. ;)

- Trixt0r

[<500 lines of code Spriter implementation]

Post the source code anyway. I guess everyone wants to see it.

[Generic Java Importer]

Hmmm... keep the "internal" version of accessing the files and keep loading with the FileHandleSCMLReader and change the SpriterLoader.load method like this:

//Gdx.app.postRunnable(new Runnable(){ //Post the creation of a OpenGL Texture to the LibGDX rendering thread.
			//This is necessary if you are loading the scml file asynchrouously with more than one thread.
			//@Override
			//public void run() {
				files.put(ref, createSprite(new Texture(pix)));
				pix.dispose();
			//}
		//});

Just comment the Runnable stuff out and keep files.put and pix.dispose.

I hope this helps, cause I do not have any clue why it crashes on android :D

Oh and change the finishedLoading method:

if(this.pack)
			//Gdx.app.postRunnable(new Runnable(){//Has to be called in the rendering thread since OpenGL textures have to be created
				//@Override
				//public void run() {
					generatePackedSprites();
				//}

			//});

if you are using the texture atlas generation.

[Generic Java Importer]

Hmm... could you please post the whole stack trace? This could give me more information about the problem.

I am not at home right now and can not test it on my android device.

I bet there is again an issue in loading files on android. Could you please try:

spriter = Spriter.getSpriter(Gdx.files.internal("monster/basic.scml").file().getAbsolutePath(), loader);
//or
Spriter.getSpriter(Gdx.files.internal("monster/basic.scml").file().getAbsoluteFile(), loader);

If this does not work, try to load the scml file like this:

FileHandleSCMLReader.getSpriter(Gdx.files.internal("monster/basic.scml"), loader);

I just wrote an extra scml reader for LibGDX specific file handles and didn't test it on android.

Or just let the code as it is and just change in the SpriterLoader class the following line

FileHandle f = Gdx.files.absolute(path);

to

FileHandle f = Gdx.files.internal(path);

Let me know if it worked.

[Generic Java Importer]

Hi Michalko,

Hmmm... I would say this error has nothing to with the library. This is an android issue, I guess.

Try to create a new android project which uses the library. Sometimes the android sdk does sometimes weird things.

Last time I tested it on android, it worked for me. I will try it again for myself.

- Trixt0r

[Spriter B5 Bug Thread]

Happens for me too, if I just click on a sprite or bone (Win7 64-bit)