jME3 Fixes

So after a talk with @pspeed earlier, I’m going to abandon for now my jme4 project and work on jme3.
So, first issue, which was temporarily brought up on the jme4 page, but was abandoned.

And when I started on that, I brought up the fact that many of the files didn’t have proper jme3 license.

I’ve identified that all of the files iirc in the com.jme3.terrain.noise package and its sub packages all use this license.

/**
 * Copyright (c) 2011, Novyon Events
 * 
 * All rights reserved.
 * 
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are met:
 * 
 * - Redistributions of source code must retain the above copyright notice, this
 * list of conditions and the following disclaimer.
 * 
 * - Redistributions in binary form must reproduce the above copyright notice,
 * this list of conditions and the following disclaimer in the documentation
 * and/or other materials provided with the distribution.
 * 
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
 * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 * 
 * @author Anthyon
 */

But another file is the Class LRUCache in package com.jme3.terrain.geomipmap which stands out from all of them.

package com.jme3.terrain.geomipmap;

// Copyright 2007 Christian d'Heureuse, Inventec Informatik AG, Zurich,
// Switzerland
// www.source-code.biz, www.inventec.ch/chdh
//
// This module is multi-licensed and may be used under the terms
// of any of the following licenses:
//
// EPL, Eclipse Public License, V1.0 or later, http://www.eclipse.org/legal
// LGPL, GNU Lesser General Public License, V2 or later,
// http://www.gnu.org/licenses/lgpl.html
// GPL, GNU General Public License, V2 or later,
// http://www.gnu.org/licenses/gpl.html
// AL, Apache License, V2.0 or later, http://www.apache.org/licenses
// BSD, BSD License, http://www.opensource.org/licenses/bsd-license.php
//
// Please contact the author if you need another license.
// This module is provided "as is", without warranties of any kind.
import java.util.ArrayList;
import java.util.Collection;
import java.util.LinkedHashMap;
import java.util.Map;

/**
 * An LRU cache, based on <code>LinkedHashMap</code>.
 * 
 * <p>
 * This cache has a fixed maximum number of elements (<code>cacheSize</code>).
 * If the cache is full and another entry is added, the LRU (least recently
 * used) entry is dropped.
 * 
 * <p>
 * This class is thread-safe. All methods of this class are synchronized.
 * 
 * <p>
 * Author: Christian d'Heureuse, Inventec Informatik AG, Zurich, Switzerland<br>
 * Multi-licensed: EPL / LGPL / GPL / AL / BSD.
 */

So I’m mostly asking if I should just leave the licenses the way they are, or update them.

First license is new-BSD (3-clausule) if you will look more carefully. so it match JME license.

But the second one, im not sure, should be changed probably.

Also please note jme3-terrain package is optional. But if you will rebuild it better and with good licenses, it might be more propular for sure.

But also please note jme3-terrain is compatible with SDK Terrain editor. - thats important. You should leave it compatible i think. (just api i mean)

Also please note it have special physics/raytrace methods(optimal for terrain ones). You should take care about it too. - i mean make sure your code will be optimal also.

And if you really want rebuild it much, i would like to see there “tiles” so could add more tiles, than just one terrain like it is now. (well it will not work in SDK editor for sure, but as additional feature out of SDK)

Also also also, dont even try make voxel terrain, there are many of voxel terrain libs, imo JME default terrain should be heightbased like it is.

Also also also also, there are NO JME PBR terain shader. But community(we) have one, so we can share it(to let you see solutions), since rebuilded terrain should also support PBR material.

But i think some people should tell whats their idea about rebuild JME terrain.

Should it be just code-rebuild?

or should it be “idea of how it works” re-plan?

or “adjust idea a little and code too”

Because im single user, but i think JME terrain should be:

  • heightbased
  • maintaining API so SDK editor would work
  • tile based - so can add tiles of terrain (but SDK would paint default on tile 0,0 ofc - until SDK could be updated too)
  • still material alphamap based - but better shader code. (imo alphamaps are good, but maybe i just dont know better solutions, anyway its required to maintain SDK editor api)

im curious about other opinions.

2 Likes

As far as I know, I don’t know how much the terrain package works with the SDK, I remember one of “buttons” in the SDK to edit something always threw an exception and of course didn’t work when you clicked it.
I’m not sure if it was the terrain though.

All I’m doing at the moment is reorganisation of packages and fixes the numerous warnings that show up in the code. Other than that I havn’t done much yet.

yes, SDK have Terrain Editor.

so there are 2 choices:

  • maintain api so Editor could still work
  • change to better API - but editor would not work.

well, best if you could update Terrain + SDK Terrain editor too.

I don’t have any experience with SDK (developing it)

And I don’t want @Darkchaos having to fix up the SDK because of something I did to the core lib, so imo the first option.

you know what i think?

best option would be add jme-terrain-v2 or something package. then no need care about SDK

so SDK will work, just with old one, so there will be time to update SDK to work also with yours new one.

because breaking SDK terrain editor seems unacceptable. (so 2 options, maintain API or new package) Well im not sure who use SDK to edit terrain, because not me, but i belive there are people for sure.

Well that would mean one got something that the other didn’t likely, which likely isn’t too good an idea.
But sure if SDK editor will eventually be based off new terrain package.

The SDK needs it own topic for maintenance, because it has much more work to be done imo than even the engine. Currently there are only 2 people working on it, and they have done great job. But when there are so few people working, it becomes out of date FAST.

Currently there are only 2 people working on it

oh, so you done your work since you know it :slight_smile:

Yes, there are 2 people, and 3.3 SDK break much(it will be new Netbeans version as i know)… so i hope this new Netbeans version will work someday hopefully. Then could work on new changes.

Yea, my ultimate goal for helping jME, (besides jME4), would be to fix up the SDK.

In meantime though, I’m working on the engine and I’ve got to finish it.

just as sidenote, SDK is optional

i just mean terrain changes should not break terrain editor, nothing more.

What would “break” the editor?

As I said earlier, I’ve mostly been reorganising the packages, I’m not sure if that affects SDK or not.

well, SDK(terrain editor) is using jme-terrain package and operate over alphamaps of TerrainLighting material as far as i know.

so it mean if you dont want break it, you should look what editor use exactly(and not change api), or just make new package.

i guess mainly editor use terrain.raytrace / terrain.setHeight methods + alphamaps of material
made my own editor some time ago based on SDK one.

I’ll look when I can over the SDK, I’ve never looked at it in depth as I have not really tried working on it any yet.

I’ll probably copy the current terrain package into separate on for “fixing up” for the time being.

here terrain editor source:

1 Like

Oh, well I might need to let the “SDK Pros” add new terrain lib support.
But I’ll keep current terrain in its own package and start a new one.

yes i agree, just start a new package, when you will done, and it will be better, the SDK will for sure be updated to use it after a time.

Well, i still anyway wait about other opinions, but i dont think like breaking SDK editor is a option here.

At the same time, besides the packages, I’m not adding anything to the code. I’m just updating the licenses and fixing warnings.

1 Like

thats ok, because need to wait for opinions of people who know what was “totally broken in JME terrain”(in code meaning).

Then could know what next.

Just FYI:

There are certain libraries that we ‘bundle’ with JME in the sense that we release them when we release JME “whole”… what the team used to call “JME core libraries”.

Of those, several are slated to be moved to their own separately managed projects… the terrain library is number three on my list. And then only because the blender loader and nifty trump it just slightly… and because I might actually get community pushback from trying to move jme-terrain.

These three libraries will probably be moved to the jme-contrib repository and then get pages in the store when someone decides to pick them up and continue with them, and so on.

Of those three, the terrain library has perhaps suffered the most because it’s hard for someone interested in fixing a bug to get involved. Find the bug, try to fix the bug, wait and wait and wait for it to get integrated into a release so it shows up in the SDK. And so on. If it is to continue as a thing it needs to be able to breathe on its own.

That being said, as much as a redesign+rewrite would be nice for jme-terrain, you will end up competing with other terrain-related libraries while not actually meeting the needs of current jme-terrain users. Whatever you do would have to remain compatible with the current API and SDK integration.

…which given that you seem to be trying to find a way to make a big impact without spending too much time learning about what came before, may not be as easy as you hope. That being said, jme-terrain really needs it and could definitely use someone to take over leadership there.

Well I’m trying to learn without getting stuck in the core lib, just yet. And terrain sounded like a good place
Somebody simply needs to create a top notch terrain lib (maybe me), and leave it as a plugin for the SDK.
Same with Blender, I guess.

Personally, NiftyGUI should be removed completely, its very difficult to use for beginners and most people don’t use it. If people need a GUI, they can grab Lemur and go from there.
And I do not mean put it in current jme libs.