Unable to locate MipMapGenerator

I downloaded the jme3 master from git hub which I am attempting to compile.

I have error, cannot find “jme3tools.converters.MipMapGenerator”

I have performed quite an extensive search to locate it but I cannot find it in any lib or web page etc.

I am hoping someone can help me out :smile:

Meh, you can put the name of the class in the search box in jme github repository.
Anyways, here it is: https://github.com/jMonkeyEngine/jmonkeyengine/blob/1b0f6d0f59650772bac4588d1733c061ff50d8c8/jme3-desktop/src/main/java/jme3tools/converters/MipMapGenerator.java

1 Like

Thanks for that! I found it in the master now…

How are you trying to build it? The normal compile has no such issue…

I am using javac to compile my own project and only putting *.java sources from the jme3 master into the compile path.

I realise that winRAR isnt very good at “finding” java files in the master jar so I have now exported all the files from the master into a directory so finding files should be ok now.

Is there a reason you are doing this the hardest way possible? I’m just wondering what your end goal is.

The problem I have is that the natives are not being handled in a way that is satisfactory to my requirement and there doesnt appear, as yet discovered, any options to customise how this is handled. The packages seem to be wrapped in autoloaders. I am investigating the source code to see if their behaviour can be customised or I will just have to modify them to suit my requirements.

Application and SimpleApplication also do not meet my requirements and with initial investigations do not appear to have the ability to be customised in a fashion that meets my requirements. I have tried to compile and run a test app with Application and SimpleApplication replaced yet cause runtime errors due to questionable dependencies. I will have to modify the source code to address these issues.

I am also experiencing errors when trying to toggle between a Canvas context and a display context. I am currently investigating a suggestion on another thread as to whether I will have to modify the source to address this issue.

The only reason I am “doing this the hardest way possible” is because, to my current knowledge, there is exactly “no other way possible”

Well, it does seem to me like you’ve taken a few potentially solvable problems and instead turned them into a really big problem. You might try swinging back and trying to solve those other problems instead.

But even if it should turn out that you have to modify the engine sources, “pulling in one .java file at a time” is a much much harder way than “forking the repository and adding custom code”.

…but really those other problems would be hard for us to help with just based on the “it doesn’t work for me” description above.

I understand what you are saying and I am only trying to solve my problems the only way I know. If there is a better way for me then please explain :smile:

I dont really understand how the repository works. I have downloaded the master and am examining it to learn how it works in mind to learn what changes I need to make to alter it to suit my needs. If there is a more efficient way then please explain :smile:

Well you don’t say what your problems are. Theres absolutely no obvious reason to change SimpleApplication to implement an Application for example so the only thing we could say is “your are deluded about what your requirements are”.

normen, If you cant add anything constructive then please shut up.

I’m trying to get some help and advice, from helpfull and constructive people…

What is “satisfactory to your requirement”?

What are your requirements that this is not meeting?

These questions are potentially far easier to address.

Unless I misunderstand, it sounds like your current approach, to use a metaphor, is that you want to swap out the wheels and drive train of a car, so you are bringing one part over at a time and then wondering why it’s not working without the gas tank, etc…

It remains to be seen that a replacement of the wheels and drive train are even necessary because we don’t know why you felt that way… but even still, bring over the whole car, lifting it up, and swapping out the wheels and drive train seem easier to me.

ie: fork JMEs master into your own repo (probably many many docs on github describe how to do this) then modify what you need. At least then you’ll have a diff of what you did and could circle back and show us since it seems difficult to describe what you needed (that so far no one else has).

But really, Application doesn’t lock you into that much… so it surprises me that you need to replace it.

Well back at you. Good luck with your approach, maybe you find some people who can read your mind.

How I dealt with the natives problem previously is that I created an interface called…


with one function…

loadNative(String name)

In the previous architecture code that I was using, where the natives were handled, I modified the code to include the following function…

setNativeLoader(NativeLoader nativeLoader)

If the internal pointer was unset, then the previous native loading was enacted. However, when set, the function call of the interface would be made and upon return the required native should be loaded into memory, and the previous native loading ignored.

The purpose of this was so I could have control over how the native files were stored prior to loading and upon loading where they were located on the users hard disk.

My issue with SimpleApplication is primarily that a root node and a guinode are defined with no ability to have an alternative scenegraph configuration. My current project operates about 8 different scene graphs, the number is dependent on the situation. The reason for this is to display several layers that make up the view and the gui. The reason for a number of scenegraphs is to ensure the structures do not interfer with eachother whilst being interactive within themselves. Also, scenegraph traversal is much more efficient in knowing only to focus on a particular scenegraph.

How I image this could be addressed within SimpleApplication is to modify it so that root node and gui node are arraylists of node. Maybe the following functions would be all that is needed to provide full funtionality…

List getRootList()
List getGuiList()

I appreaciate that this functionality may already be available in another guise within the architecture of jme3 so I appologise for my lack of knowledge and I would appreciate an explanation on how I could configure jme3 to meet my requirements in this matter.

I may have a solution for toggling an applet canvas and a fullscreen display, as dicussed on another thread, but I have yet to determin this.

I hope I have answered your questions with explanations of the problems that I need to address and the potential solutions that I have provided in a sufficient manner to be understood.

ps. I am glad you asked these questions because, as highlighted by normen, I was becoming conerned with the lack of ability to read my mind :smile:

JME does this differently and automatically in a way that works on multiple platforms. Different doesn’t mean wrong though. So you’d have to say why what JME is doing doesn’t work in your situation.

Why would this be any different than the child list of rootNode and guiNode? Do you know you can create your own viewports and/or just swap out the nodes of your scene graphs as you want? The scene graph is just a node and it’s children after all.

SimpleApplication defines a couple things that you might not use… but so what? No harm done. You could even completely ignore rootNode if you wanted to but I don’t know why you’d want to. I see no material benefit in having an array list versus just using the children of root node itself.

Actually, that was kind of the second time I asked… which is why maybe normen was bristling. We get a lot of people who have much less thoughtful posts that amount to “I’m holding a piece of string, can someone tell me how long it is?” ie:a sum total post of “This code isn’t working. Can someone tell me how to fix it?” Well, no… not really.

At any rate, many people have used JME successfully. Very few have decided to rewrite it to suit their needs… so there is usually some way to do what you want and still leverage the experience and bug fixes that already exist in the code.

I dont believe it was “kind of” the second time you asked… anyhow…

I never said JME did anything wrong. My exact term was “doesnt meet my requirements.” How would you prefer me to express myself with this meaning without offending anyone?

My approach has been to seek help and advice. I did not give offence in seeking help and advice. People take offence of their own accord and then chose to become antagonistic and start name calling. This is not my purpose and I cannot control how people conduct themselves.

As we both have confirmed that there is nothing wrong with how JME handles natives, I would also like to confirm there is nothing wrong with the way I wish to handle natives. My statement “does not meet my requirements” still stands as I am seemingly unable to configure JME to handle natives to my requirements. Please remember that it is not my requirements that are in question but my ability to configure JME to meet my requirements.

I have offered a solution to how the native handling can meet my requirements which has successfully worked with other 3D engines. I am very happy for you to suggest an alternative way for me to configure JME so that I can indeed handle the native loading in a manner of my choosing.

I am very surprised to hear that the people who have written JME seem battered and defensive of JME when they should be very proud of themselves. There are always going to be people who do things differently or that JME isnt able to answer their requirements. There is nothing wrong with the approach JME uses and with that we should also remember there is nothing wrong with the approach that other people use either.

I accept your point that Node is an array of Nodes and should be sufficient for my requirements. I apologise for failing to initially see it in this way. I will really appreciate if you can explain how each child can be rendered in its entirety in z order without interfering with the other children regardless of distance from the camera. For example if an object in the first child is 1m from the camera, I need that rendered before an object that is 100m away from the camera in the second child. This is what I mean by needing each scene graph independent of each other. I would like an explanation on how to achieve this please.


Just in case I didnt express myself in a clear manner.

What I mean by independent scene graphs is that each child of root node I require rendering in its entirity meaning that all the children of the first child of root will be rendered appropriate to their distance from the camera and then the second child of root (this may in fact be in reverse order for the first child to appear on top). To reiterate, an object in the first child node at 1m distance from the camera should appear before an object at 10m in the first child node but will be rendered behind an object at 10m that is in the second node.

I hope I have explained this well enough.

Ah, as we learn a little more about the specifics it becomes clearer. What you want is viewports in that case, I guess. Then each separate viewport’s scene graph gets rendered in the order of those viewports. (And you will have to manage the root.updateLogicalState(), etc. calls that normally JME manages for you. If you search the forum for something like ViewPortAppState then you might see an example of doing this with an app state.) Each viewport can have its own scene, camera, clear flags, etc… they are rendered separately.

re: the natives, I get that it doesn’t meet your requirements but it is unclear why those are requirements. If someone posts that they want to have JME copy their application five times and delete the first four copies or something then we might also logically ask why that is required. From my perspective, without knowing the reasons I’m left to wonder if it’s just some similarly crazy thing or not. Your requirements may be perfectly valid but we don’t know that… thus we will try to steer you to the easier way (like with the multiple scene graph issue).

Note also that the native loading is changing in 3.1 to better work with the various library distributions that JME works with. The reason I personally would be wary of trying to change it is because I’ve been witness to the various platform-specific bugs over the years that have since been fixed. Some thing will work here but fail on Windows version umptifrump or work on that but fail on MacOS10.1.2.3. or whatever.

Thank you for that explanation. I thought it would be something on similar lines.

My main concern at this point is whether different ViewPorts can traverse the same scene graph without conflict which I am sure they can but a confirmation would be very nice.

I notice that when I set rootNode and guiNode to null in SimpleApplication, a null pointer error occurs. Considering that everything that is going to be rendered is going to be via ViewPorts that I have configured it concerns me why the system remains dependent on these 2 nodes that I am never going to use.

My concerns for the natives is that I need to ensure that any previous carnations are deleted, this is for security and I am adamant about this. Can you confirm to me that previous copies are deleted before new copies are created? I will try to cope with being subject to a system that may or may not take care of things to my liking.

I find it odd that when using javaw the natives are created in the same location and litter the directory. Is it not possible for them to be created in a temporary cache? which is my preferred method.

I have made a lot of effort going from, this is how I do things, to, what are my requirements and how easily can they be met. I have never said that JME does things in a wrong way. I am just trying to meet my requirements which is also not wrong. I am quite disappointed to receive such abuse as being called delusional and crazy. You should be ashamed of yourselves and I urge you to try to be less abusive towards people in the future.

I am very grateful for your help and support.