Regarding the terrain library, I’m off to work on doing some cleanup, should I add the jME license at the start of each file? Most of them don’t have such a header.
1 Like
That’s issue 1001. It’s a tricky issue, in my opinion.
I’m uncomfortable slapping new licenses on files I didn’t create. If we can determine the author, I think we should at least attempt to contact them to ask their intent. In cases where the author is unknown, the person who submitted the PR and/or integrated it might have some insight.
3 Likes
im happy you work on it. 
Just as a note, i might be wrong, but if someone push a code file without ANY license, imo he agreed this files to be under project general license, because he pushed it and didnt specify own one.
Each file should anyway have license, true.
The most important anyway is to have everything new BSD there. if you seen GPL it should really be get rid of.
1 Like
Agreed. The only problematic cases are when there IS a separate license in the file… and it’s not the same or incompatible.
2 Likes
Don’t you agree to that in any case? Like I can’t just commit code and say “this is my proprietary license, every download costs 10$”. But I guess it’s an attorneys job to discuss whether the repo owner would have to reject such commits or whether the code automatically falls under the repositories ownership/licensing.
It’s actually tricky, because iirc you don’t loose ownership over your code and thus can re-release it under a different license for a different project.
2 Likes
yes, you are right.
It’s actually tricky, because iirc you don’t loose ownership over your code and thus can re-release it under a different license for a different project.
I remember there already were situations where same code were under 2 licenses. It were just going different changes from basecode.
simple example is that someone take JME and rebrand it and push as “general” different license, because well… he can. Fact that noone will use it, but still… he change some file under new-bsd and add own methods and rebrand it to GPL for example. (since GPL is over new-bsd, cant be done other way - cant be changed from GPL to new-bsd). So if any GPL file exist in JME, should be removed and written own way. (i hope there are none) So idk how it would refer to 10$ license like you said. All i know that JME is marked as new-bsd, it means user should not look whats inside, because he already receive general information. its just more about “stick” to this information really. Lets now assume Unity have its license, but its partially closed-source (not all open) then how you could even know if all files in closed-source are same license?(since some licensed dont affect just a code) you dont know, but you have general note only. All of this is very hard and require attorneys job like you said.
What i dont like myself in GPL is that someone who is GPL file owner can ask you for a sourcecode of your published project. That is unacceptable. Ofc, not every GPL owner do that(its tricky), but they can.
And ofc GPL is like coronavirus that infect other projects that use it also need to be GPL…
What about work done in PR 1078 ?
It includes:
- Adds BufferObject to correspond to BufferObject
- VertexBuffer now extends BufferObject
This change I did after a brief discussion with @pspeed on discord 10 months ago. Now, I do not know if this is how you envisioned it, or if you hold a different opinion now, but it would be nice to hear your current opinion on this matter.
Next,
- QueryObject is added to support queries
- RasterizerDiscard option
- TransformFeedback is implemented using all of the above
- finally, the changes were done so as not to break backward compability
1 Like
Ultimately, I defer to ric on stuff like that. I’ll take a look again this weekend to see if I have a “java code” opinion on it.
Most of the terrain files are written by Brent Owens, but I’ve seen some by normen. But some don’t list their author at all.
1 Like
You said in your roadmap to remove lwjgl, but it looks like we need it for the new renderer?
1 Like
he probably mean lwjgl2(jme-lwjgl), where lwjgl3(jme-lwjgl3) will be used.
2 Likes
Yes, @oxplay2 is absolutely correct. We have two different opengl renderers: jme-lwjgl based on lwjgl2, and jme-lwjgl3 based on lwjgl3.
At this point LWJGL 2 is completely deprecated, last release Jan 18th, 2015.
LWJGL 3 is the replacement for it, and is actively maintained with new features added.
1 Like
It is hard for me to work on the core library where that is handled because it is such a mess in there. But I’ll slowly work up a way to remove lwjgl2 and before.
I believe that all that is required is to remove the module, as jme3-lwjgl3 is a drop in replacement.
1 Like
That is correct. But there are few issues with LWJGL3 that need to be addressed first. I’m not gonna elaborate and start the recurring discussion on this. Issues on GitHub are mostly up-to-date, forum has some additional bits perhaps.
1 Like
Supporting Java 9+ is a good idea in general, but I’m not following on the graphics formats - ImageIO has been able to load PNG for quite some time, and there’s still no core JDK support for rendering SVGs to bitmaps.
Using java 9+ allows supports many new file types including .svg graphics.
When I get home off I’ll post a roadmap.
The only SVG support in the core JDK that I’m familiar with is in JavaFX, which was spun off into its own project around Java 11, so it’s no longer core. SVG isn’t easy to support (this isn’t unique to Java - even browsers don’t always support/render the newer SVG specs correctly).
Thats what I’m planning to switch to, currently we are using awt/swing to create jme window, but those are being replaced over time by JavaFX
1 Like
Improved support for JavaFX would be great, but I think we might have a better time of it if we moved native window creation to GLFW rather than tying it to a specific UI toolkit.