Blocks

QcO · December 10, 2019, 3:56pm

Thank you!

Ali_RS · December 22, 2019, 10:06am

remy_vd:

It is however possible to add a PBR material and use it on a block:
// register the PBR material
TypeRegistry typeRegister = BlocksConfig.getInstance().getTypeRegistry();
typeRegister.register("my-pbr-material", "/path/to/my/pbr-material.j3m");

// create block that uses the PBR material and register it
Block pbrBlock = Block.create("my-pbr-block", "my-pbr-material");

BlockRegistry blockRegister = BlocksConfig.getInstance().getBlockRegistry();
blockRegister.register(pbrBlock);
In the end the MeshGenerator will create a geometry of the mesh with the PBR material. You will still need to to whatever light calculations you need to do to render it, but I guess it should be possible! Feel free to try it out and let me know

Sorry for the late reply, I finally had a chance to give it a try, and seems it does not work.

java.lang.IllegalArgumentException: Material parameter is not defined: DiffuseMap
	at com.jme3.material.Material.checkSetParam(Material.java:467) ~[jme3-core-3.3.0-beta1.jar:3.3.0-beta1]
	at com.jme3.material.Material.setTextureParam(Material.java:536) ~[jme3-core-3.3.0-beta1.jar:3.3.0-beta1]
	at com.jme3.material.Material.setTexture(Material.java:608) ~[jme3-core-3.3.0-beta1.jar:3.3.0-beta1]
	at com.rvandoosselaer.blocks.TypeRegistry.setTextures(TypeRegistry.java:140) ~[blocks-1.1.1-SNAPSHOT.jar:?]
	at com.rvandoosselaer.blocks.TypeRegistry.register(TypeRegistry.java:67) ~[blocks-1.1.1-SNAPSHOT.jar:?]
	at com.rvandoosselaer.blocks.examples.SingleBlock.simpleInitApp(SingleBlock.java:59) ~[main/:?]
	at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:239) ~[jme3-core-3.3.0-beta1.jar:3.3.0-beta1]
	at com.jme3.system.lwjgl.LwjglWindow.initInThread(LwjglWindow.java:475) ~[jme3-lwjgl3-3.2.3-stable.jar:3.2-stable]
	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:574) ~[jme3-lwjgl3-3.2.3-stable.jar:3.2-stable]
	at com.jme3.system.lwjgl.LwjglWindow.create(LwjglWindow.java:423) ~[jme3-lwjgl3-3.2.3-stable.jar:3.2-stable]
	at com.jme3.app.LegacyApplication.start(LegacyApplication.java:463) ~[jme3-core-3.3.0-beta1.jar:3.3.0-beta1]
	at com.jme3.app.LegacyApplication.start(LegacyApplication.java:424) ~[jme3-core-3.3.0-beta1.jar:3.3.0-beta1]
	at com.jme3.app.SimpleApplication.start(SimpleApplication.java:127) ~[jme3-core-3.3.0-beta1.jar:3.3.0-beta1]
	at com.rvandoosselaer.blocks.examples.SingleBlock.main(SingleBlock.java:34) ~[main/:?]

It’s because in the below line it tries to overwrite textures on material while there is no DiffuesMap slot available in PBR material.

github.com

rvandoosselaer/Blocks/blob/ae56bf4a31d31bdd94ee9ad1c6d40cc7e13a5328/src/main/java/com/rvandoosselaer/blocks/TypeRegistry.java#L67


      
          
          public Material register(@NonNull String name, @NonNull String materialPath) {
              return register(name, load(materialPath));
          }
          
          public Material register(@NonNull String name, @NonNull Material material) {
              if (name.isEmpty()) {
                  throw new IllegalArgumentException("Invalid type name " + name + " specified.");
              }
          
              Material m = setTextures(name, material.clone());
          
              registry.put(name, m);
              if (log.isTraceEnabled()) {
                  log.trace("Registered type {} -> {}", name, material);
              }
              return material;
          }
          
          public Material get(String name) {
              Material material = registry.get(name);

remy_vd · December 22, 2019, 10:21am

Hi,
indeed when the texture doesn’t have a ‘DiffuseMap’ key it will fail, didn’t think of that.

I’ll be releasing a new version of Blocks in the coming days. This will include a rounded block shape, will use @sgold’s Minie library as default physics library instead of bullet and has some small bug fixes.

I’ll see if I can squeeze this issue also in the release.

Ali_RS · December 22, 2019, 10:23am

Thank you so much

Ali_RS · December 23, 2019, 5:23pm

Will appreciate if you can also update the BlockBuilder example to work with different block scales. When setting block scale other than 1 editor does not behave as expected.

Edit:

I guess these methods in ChunkManager :

getChunkLocation()
getBlockLocation()
getNeighbourBlockLocation()
addBlock()
removeBlock()

need to take the block scale into account when finding chunk/block location Vec3i?

remy_vd · December 27, 2019, 10:57am

This has been fixed on master

Ali_RS · December 27, 2019, 12:15pm

Thank you so much

Have some feedbacks regarding theming.

Currently, the way TypeRegistry works is that it gets a path provided by BlocksTheme and based on block type it loads proper textures (DiffuseMap, NormalMap, ParallaxMap) from that path and creates a Lighting material and sets the textures on it.

My suggestion would be to treat a theme as a directory of materials (j3m files) instead of texture files. Thus a block type would refer to the name of the material file inside the theme directory. (ex material “grass.j3m”)

So users can create and export materials with whatever tools and whatever material type they want (PBR, Lighting,…) then in the TypeRegistry class you would just need to load the proper j3m file based on the block type and theme directory path.

The first benefit is that TypeRegistry will not depend on a specific material type and the next benefit is that users can share the same material for the types they want through different themes without needing to copy the texture files around, just need to copy the material file.
For example, say I have two themes, “spring” and “autumn” and I want to use the same texture for the sand block in both themes, then I just need to copy the material file into the new theme without needing to copy the actual texture files again. (I hope I have made the idea clear)

Note it’s just a rough idea, I am not sure if it will fit well into your design, but anyway I hope you find it useful.

Ali_RS · December 27, 2019, 5:46pm

Looking into master branch I could not find where the automatic chunk storing is happening. Looking into branch v1.1-master and wiki page, seems BlockManager uses a storeInterval time to regularly save chunks into a file.

Has the behavior changed in master branch?

Ali_RS · December 28, 2019, 12:57pm

Have one more suggestion
Sorry for spamming the thread with my suggestions

It will be nice if you let user to be able to register a listener to get notified when a page attached/detached in the Pager class.

Something like this:

public interface PageListener<T> {

    public void onPageAttached(Vec3i location, T page);

    public void onPageChanged(Vec3i location, T oldPage, T newPage);

    public void onPageDetached(Vec3i location, T page);

}

to get called from attachPageAtLocation(), detachPageAtLocation() and updatePages() methods within the Pager class.

this will be useful for managing attachment of game objects sitting on the chunk. For example, we want to detach trees, landscapes,… when chunk gets detached and attach them back when the chunk gets attached again.

Thanks

remy_vd · January 3, 2020, 11:38am

A new version of Blocks is released. Blocks v1.2.0 is pushed to bintray and is available on the jmonkeystore.

The highlights of this version are:

Renamed BlocksManager to ChunkManager with a refactor on the interface
Using Minie 1.2.0for33 as the default physics library instead of bullet
A new rounded cube shape

The complete release notes can be found on github.

Gradle snippet to use Blocks in your application:

repositories {
    maven {
        url  "https://dl.bintray.com/remyvd/rvandoosselaer" 
    }
}

dependencies {
    compile 'com.rvandoosselaer:blocks:1.2.0'
}

The next version of Blocks will focus on the theming part. Adding PBR support and include an overhaul on the TypeRegistry interface. I still need to rethink it a couple more times.

Ali_RS · January 3, 2020, 11:58am

Thanks

jayfella · January 3, 2020, 2:48pm

I’m glad to see this choice finally getting some traction!

Ali_RS · January 3, 2020, 3:11pm

@remy_vd seems rounded cube does not support adjacent face culling, any plan to add support for it?

remy_vd · January 3, 2020, 3:34pm

Well, face culling for rounded shapes is a bit harder. Depending on what face you would like to cull, the ‘edges’ of the face change. Eg. if you want to cull the front face of a rounded cube, you don’t want the rounded edges of the front face to be part of the culled face, otherwise you would have holes in your mesh. But in another scenario the rounded edges should be part of the face.

You can always overwrite the function that checks if a face of 2 neighbouring blocks should be rendered: Chunk#setFaceVisibleFunction but it’s not as easy as just adding the rounded shape to it…

I do have some ideas on how to solve It, but this was not intended to be part of this release. At this moment round shapes should be used sparingly as the triangle count goes up exponential.

Ali_RS · January 3, 2020, 3:43pm

I see, thanks for explanation.

remy_vd · January 9, 2020, 1:14pm

A new version of Blocks is released. Blocks v1.2.1 is pushed to bintray and is available on the jmonkeystore.. This version bumped the Minie physics library to 1.3.0for33

Ali_RS · January 9, 2020, 3:26pm

There is a very nice gradient block theme available for free in Free 3D Models & Textures in case you like to add them to your library.
(Note, have not checked what is their license exactly)

remy_vd · March 4, 2020, 12:22pm

A new version of Blocks is released. Blocks v1.3.0 is pushed to bintray and is available on the jmonkeystore.

What’s new in this release:

Updated physics library Minie to version 1.4.0for33
Updated gradle wrapper to version 6.2
Added the ability to remove blocks from the BlockRegistry
Changed visibility to public of the #isFaceVisible() and #getNeighbour() methods in the Chunk class

A next release is coming out soon that will revamp the theming part of Blocks. I wanted to push these smaller changes out before the big update.

Want to say thanks to @Ali_RS and @sgold for the support and ideas in Blocks.

remy_vd · March 10, 2020, 7:57pm

A new version of Blocks is released. Blocks v1.4.0 is pushed to Bintray and is available on the jmonkeystore.

What’s new in this release:

An overhaul of the TypeRegistry and the Theming system
Add a PBR version of the water type block

The complete release notes can be found on github.

Registering a custom material

It’s now possible to register a custom material for a type:

Material myGrassMaterial = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
myGrassMaterial.setColor("Color", ColorRGBA.Green);

TypeRegistry typeRegistry = BlocksConfig.getInstance().getTypeRegistry();
typeRegistry.register(TypeIds.GRASS, myGrassMaterial);

Using a theme

Material files can now be placed in a theme folder. When you add the dirt.j3m material in the theme’s folder, it will be used for the dirt type block.

It’s also no longer necessary to use an image editor to create the ‘combined’ textures of a block. Previously you had to merge the top, side and middle texture in one image, like this:

Now you can place the 3 separate images in the theme’s folder and the TypeRegistry will combine these 3 images into one texture at runtime.

Some images of the PBRBlock application in the examples project:

Ali_RS · March 12, 2020, 1:38pm

Thanks so much for the new release.

Coming up with a new idea

It’s about remote chunk repository in networked games.

The Idea is that client should be able to use a “RemoteChunkRepository” to fetch chunk data from the server. It’s a read-only repository and an attempt to save chunk from client should fail with an exception. The server itself then will utilize a File-based repository to load chunk and return it to clien. There needs to be an “AbstractClientService” on client side and an “AbstractHostedConnectionService” on server side for communicating through JME RMI.

I am not yet clear in what form chunk data should be stored in server so that each scene has it’s chunks data separated from other scenes. (note we have multiple scenes running in online games and each scene has it’s own chunks data).

Should it be a directory-based structure? (a folder for each scene) or an ID-based structure? (everything in a flat directory with unique chunk id) or something else? How it is done in other games like Minecraft?

Anyway, I hope you find the idea interesting to play with.

I also will appreciate any comments from other guys about this.

Regards