Hello.
I have two and a half suggestions today:
1.
I’d like some way to manually edit/control how lods are created/generated.
As i understand, there are two ways today:
Either create your own VertexBuffers through code, or
Auto generate them through the “Advanced Ogre Xml Importer”
It seems to me that the automated way works better for high poly, concave meshes than it does for low poly complex meshes (since low poly is more “sensitive” where optimization happens).
I’ve seen that the teapot .xml file used in the “Stress Test” has lod levels in the actual source file.
Would it somehow be possibly to extend the Importer to support pre made lods? Or alternatively, be able to preview or modify how the automated system does its lods?
1.5.
And whilst speaking of the Advanced Importer. Using the regular ogre importer, i don’t need a material file, but if i don’t have a correct material file when using the Advanced Importer, it gets stuck at “50%”. Is there a specific reason why the Advanced one needs a material, when the regular importer doesn’t?
2.
Would it be possible to get support for adding Controls (like LodControl, AnimControl, BillboardControl) to a geometry in jmp?
Thanks!
- Yeah, would definitely be nice… Just loading models “into” lod levels.
1.5) Idk, when is 50%? Does it run the command line tool at that moment?
- Yeah, you can add any kind of Control just as easily as any kind of Node: The SceneExplorer :: jMonkeyEngine Docs
1.5) is a NPE when looking for the (missing) material file. We talked once about it, and agreed that fixing it would be a nice warm up for me to get more into JMP…but I got sidetracked 
the “classic” import in that case throws a warning and use the RedColor material, I guess we could do the same for advanced export.
Hi All,
I wanted to put these suggestions in here because I think they are pretty important:
- I love what you are doing with / to JME 3.0. The fact that it is a single download which you install and it has NetBeans already set up with custom JME stuff is brilliant. This is 110% what JME needed.
- The assets and everything are perfect, this is exactly what JME needs. The importer, however, is awful. It doesn’t accept many file formats, for those it can try to accept, it still has a hard time. I’d be focusing on the very core stuff like model importing right now because if people can’t figure it out, they’re going to leave JME.
- A lot of the UI for the TerrainEditor and SceneEditors is pretty bad. A few fundamental design lessons should always be adhered to:
- You should be able to see as much as you can on one screen without scrolling. For areas where you do need to scroll, you should only ever be scrolling in a single direction.
- Proper grammar and spelling is important in programs for their intuitiveness and for their sense of professionalism. Things like “open model…” should be rewritten as “Select Model File,” and always keep in mind that the “…” indicates that a new dialog window is going to be opened.
I love the direction you’re going in and I’m so glad to see that Google Summer of Code is involved. As a University student, I know that you’ll be getting lots of talented people from GSoC to help out. I’d love to help contribute, too! Right now I’m just kinda figuring out time stuff.
- Thanks, we think so too
- Yeah, its dependent on working importer modules (normal jME3 loaders), of which there are not many for jME3 at the moment, I want to create a jME2 to jME3 converter at some time and use that to bridge the old jME2 importers. Apart from that you can install (unsupported) model importers from the update center and try these… But its all a WIP, as well as the UI and problem feedback of the model importer
- Yes, the accessibility and visuals of the editors has not been worked on much yet. I can only speak for SceneComposer and its visually representing its unfinished state. Mouse handling is in its first iteration and selecting and moving items is also very very basic. As soon as its nice and shiny you can be sure its at a point where most planned features have been implemented and I am ready to accept input like “put that on the right mouse button” or “move that button over there” or “make this button work like it does in software X”
Thanks for the input,
Normen
P.S. We’re not accepted yet for GSoC, so keep your fingers crossed
Of course. I don’t want to come off like I’m saying “this isn’t good enough for me,” because that’s certainly not what I’m saying. JME has come leaps and bounds removing all of the excessive coding programmers previously had to do (my high school senior project was incredibly basic and was 10,000 lines of code).
I just really hope to see JME evolve into a professional 3D engine, and should my technology startup ever take off I hope to branch a media company (video games, clearly) that could offer more support to jME. I wish I had more time / less school so I could spend some time developing for you guys.
Is there any type of guide for developing NetBeans plugins like you have been (SceneExplorer)? Maybe if I read that I could make a few edits and contribute them? A while ago I started something called “Project Genesis” which I could steal some of my heightmap-smoothing algorithms from, etc.
Yeah, I created an API for jMP plugin programming in NetBeans and try to document it best I can (WIP, changes unavoidable) here. That page also contains general links and info about NB platform. NetBeans platform itself is quite well documented, just try looking on their page instead of googling 
Theres a contribution svn repository for plugins that you can commit plugins to so they appear in the update center (we want to make all jMP plugins and also normal jME3 libraries available this way) and the source of the SDK editors is available in the jme svn trunk along with the engine, you’re welcome to contribute 
Edit: Didn’t take your input in a negative way at all, its very constructive, thanks!
@Trussel: Can you tell us more about the importer issues you were having? Currently the core supported formats are OBJ and OgreXML, if there’s any issues you encounter please explain so we can fix them. Please open a new thread for that.
When i convert obj to j3o: uv coordinates are flipped when i assign lighting material.
There is no such issue with ogre to j3o.
mifth said:
When i convert obj to j3o: uv coordinates are flipped when i assign lighting material.
There is no such issue with ogre to j3o.
Looks like there's an inconsistency ... From what I see:
assetManager.loadTexture() : flips by default
OBJ Loader : flips by default
OgreXML Loader: does not flip by default
The question is, which standard should we adopt, it seems like various exporters might export models in different ways ...
However for OgreXML it seems the default works for most people.
i think without any flipping would be great.
Hi guys,
New poster here, I’m trying out the JMP for a game I’m wanting to develop.
Anyway, while trying to get the first tutorial to run, I ran into problems. I’m using Eclipse as my IDE, and discovered I was having problems due to LWJGL not being installed and set up as an external JAR for Eclipse. Please can I suggest that the documentation for setting up Eclipse as an IDE include a mention of this fact. A link to this page would help anyone who is stuck with it.
Thanks guys.
Suggesting how to set up Eclipse bears no relevance to jMonkeyPlatform whatsoever, sorry. If you are experiencing issues, please start a new thread. It sounds like you’ve misunderstood how jMP is supposed to be used (read: not mixed with Eclipse). Start with the wiki index and learn your way from there.
Welcome to the forum
If jMonkeyPlatform refers to the IDE then yes I suppose I am confused. Can you suggest where I should post that instead?
Is there a concise definition of the difference between jMonkeyPlatform and jMonkeyEngine?
I think the first page of the wiki explains if pretty well. jMonkeyPlatform refers to the IDE, yes, in other words the jMonkeyEngine 3 SDK. Try download Alpha-4, no Eclipse involved, and try get comfortable working with that environment; it will make developing with jMonkeyEngine a lot easier.
Hmmm the JMonkeyPlatform IDE, or perhaps more specifically the code completion parts of NetBeans, does seem to be more my taste, but I dont like the idea of a project so tightly coupled to a particular IDE that its impossible to use any other.
Please refer me to a place that I could suggest an update to that particular setup page.
ancalagon said:
But I dont like the idea of a project so tightly coupled to a particular IDE that its impossible to use any other.
That is not true for NetBeans, it uses standard ANT projects that can be opened anywhere and compiled from command line too. Eclipse is the IDE that does nothing according to standards, neither UI nor projects.
When starting an application in JMP, it doesnt seem to care if your texture is Textures/bleh.png or textures/bleh.png, works fine both ways. But if you build it, and start the .jar, it is case sensitive. I would prefer it to either crash or not crash on both occasions, or maybe a case sensitive highlighting to asset loader lines, telling me if an asset does not exist or might cause trouble because it’s misstyped.
Yeah, the thing is that when your filesystem is not case sensitive you wont notice that, you cannot tell if the real filename is upper or lower case on such a system… During development the data is stored in a folder, after its built its in a jar file and classpaths are case sensitive. So… get an OS with a proper filesystem and without letters for drive names
Maybe, this is not a “new” feature but I’m will be happy if in beta relase of JMP will be fixed bugs with frezing and OpenGL2 window