Ludum Dare 41

Discourse is in the wrong here… probably no surprise, I guess.

I guess you could stick it behind a URL shortener if you don’t want people to have to hand type it… just too bad it doesn’t work right by default.

We are live!

https://ldjam.com/events/ludum-dare/41/storming-sands

(really hope this link works)

2 Likes

Also whoever took this pic on our team needs an award:

I can fully recommend you guys try this random project out, it’s really fun to play :smile:

11 Likes

Hi all.

My game is also live!

Get it here: https://ldjam.com/events/ludum-dare/41/black-jack-racing

Please check it out.

8 Likes

Congrats to everyone, it’s really inspiring to see games like this made with JME in a week end.
Whenever you have time, It’d be great to have a post mortem of how the dev / art went on. What was hard what was easy, what was fun, what was a pain.
Also I’d like feed back on PBR.
Thanks a lot.

2 Likes

You really would not haha

So far we’ve found (possibly) that the apparent internal thread that generates the light probe isn’t a daemon one and stays up if the app is closed during the generation time. And it’ a pretty long generation time.

Well… first it’s really not meant to be done at run time. It’s meant to be done at design time and the probes saved with their maps and params in the J3o. Then you can load them directly and it’s pretty fast.

About the threads, There are 7 threads spawned when generating a probe one for the spherical harmonics, and one for each face of the cubemap.
It’s possible they are not properly cleaned up when shutting down the app in the middle of a generation yes.

It’s long yeah. At best a few seconds.

IMO for it to be really usable in game, it needs to be offloaded to the GPU. But as said… this should be done at design time. There is no reason to generate it when launching the game in this type of game.

Apart from sdk not supporting hdri skyboxes although engine does. We didnt even bother trying jmb. So you effectively can’t do this at design time unless you write your own editor, since there’s no point in generating it if the scene is not fully assembled. But I see how it was intended to be used.

Mhhh last time I checked it did. Are you absolutely sure? The SDK is using whatever the engine can load. If you have a .hdr it should work.

Also the fact that we run it every time a new game is started along with destroying and remaking bullet every time didn’t exactly help our case of a bad loading freeze :slight_smile:

Although it’s kind of lame that one needs to use a custom editor to get this generated. It would be a lot better if there was some sort of way to write it to a file from the engine itself.

Mhh and how do you think the editors do?

This is how you can do it from the code in TestPBRLighting:

final LightProbe probe = LightProbeFactory.makeProbe(stateManager.getState(EnvironmentCamera.class), rootNode, new JobProgressAdapter<LightProbe>() {

    @Override
    public void done(LightProbe result) {
        System.err.println("Done rendering env maps");
//Saving
        Node probeNode = new Node("The node with the probe");
        probeNode.addLight(result);
        BinaryExporter ex = new BinaryExporter();
        try {
            ex.save(probeNode, new File("path/to/the/file.j3o"));
        } catch (IOException e) {
            e.printStackTrace();
        }
//done saving
    }
});

Then you just have to load the j3o, and attach your scene to the loaded Node. Or you can fetch the light on the node this way:

LightProbe probe = (LightProbe) probeNode.getLocalLightList().iterator().next();

And do whatever you want with it.

I’ll add an example in the example project.

EDIT: you can even directly save the probe, without adding it to a Node and save the node. Though I don’t recommend it since usually people expects loading a j3o will return a spatial.
Though you could even have a custom extension like “.probe” or whatever and register it with the asset manager.

1 Like

Absolutely sure. It’s not that it is not capable of loading them, but the new skybox wizard only accepts images with 1:1 aspect ratio, which is not the case with equirect maps. There’s a github issue about that but it doesnt seem anyone will fix it anytime soon.

rhaa ok… I’m sorry for this

So does that mean that jme can handle any texture size for every skybox or do they have to be hdr files?
I mean actually we could also go the idiotic way of just let it throw an exception and make the user handle it

Edit: Silence the validation of textures being square (See #162) · jMonkeyEngine/sdk@06161cd · GitHub
However OSS sometimes means doing it on your own if you need it to be done

It should be capable of eating any texture (afaik) as long as the mode is set to equirect map. Hdris usually come with a .jpg/.hdr skybox and .hdr lighting map.

And I was in the middle of a ludum dare, so there was not enough time to fix it myself.