Hey,
I’ve collected a few bugs i’ve encountered in the new SceneExplorer. For contexts sake, i think they were all found when editing particle emitters:
1.
The first time the SceneExplorer tab is clicked (if minimized) after having been closed it is instantly closed again. Happens every time a new item is selected
2.
Sometimes when selecting different objects in the open gl window, the properties window starts to cycle between previously selected objects
3.
NPE when moving emitting emitter from one spatial to another (fails to create material?) cloning problems? Also seems to occur after having changed some values on existing emitters?
No stack in jmp. When using the emitter in jme, the stack says:
Exception in thread “LWJGL Renderer Thread” java.lang.NullPointerException
at com.jme3.effect.ParticleEmitter$ParticleEmitterControl.update(ParticleEmitter.java:138)
at com.jme3.scene.Spatial.runControlUpdate(Spatial.java:540)
at com.jme3.scene.Spatial.updateLogicalState(Spatial.java:658)
at com.jme3.scene.Node.updateLogicalState(Node.java:153)
at com.jme3.scene.Node.updateLogicalState(Node.java:153)
at com.jme3.scene.Node.upda
Edit: Regarding 3. I wonder if i get it when i edit Particle Emitters that were create before the ParticleEmitterControl was created? I’ve been using the same ones for quite a while. In that case they work fine until i edit them, so perhaps it’s in write() or clone(). I can’t see any problems in those methods though.
Thanks, will look into these.
- First time i right-click on a project after jmp is launched, i get the following (non-stopping) exception:
java.lang.IllegalArgumentException: Not a DataFolder: MultiFileObject@74cce40c[Actions/Edit/org-openide-actions-DeleteAction.instance] (was a org.openide.loaders.InstanceDataObject) (file is folder? false)
at org.openide.loaders.DataFolder.findFolder(DataFolder.java:545)
at org.netbeans.modules.settings.RecognizeInstanceObjects$OverObjects.delegates(RecognizeInstanceObjects.java:122)
at org.netbeans.modules.settings.RecognizeInstanceObjects$OverObjects.(RecognizeInstanceObjects.java:85)
at org.netbeans.modules.settings.RecognizeInstanceObjects.create(RecognizeInstanceObjects.java:74)
at org.openide.util.lookup.implspi.NamedServicesProvider.lookupObject(NamedServicesProvider.java:158)
at org.openide.util.lookup.implspi.NamedServicesProvider.getConfigObject(NamedServicesProvider.java:117)
at org.openide.filesystems.FileUtil.getConfigObject(FileUtil.java:2243)
[catch] at org.netbeans.modules.project.ui.actions.Actions.deleteProject(Actions.java:239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.netbeans.core.startup.layers.BinaryFS$AttrImpl$MethodAndParams.invoke(BinaryFS.java:626)
at org.netbeans.core.startup.layers.BinaryFS$AttrImpl.getValue(BinaryFS.java:556)
at org.netbeans.core.startup.layers.BinaryFS$BFSBase.getAttribute(BinaryFS.java:402)
at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:928)
at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:861)
at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:924)
at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:861)
at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:786)
at org.openide.loaders.InstanceDataObject$Ser.instanceCreate(InstanceDataObject.java:1373)
at org.openide.loaders.InstanceDataObject.instanceCreate(InstanceDataObject.java:821)
at org.openide.loaders.FolderLookup$ICItem.getInstance(FolderLookup.java:594)
at org.openide.util.Utilities.actionsForPath(Utilities.java:2840)
- It seems the OpenGL window is leaking memory. With it open, memory constantly increases with close to 10mb/~1s until the GC comes and cleans up. Closing it seems to keep the memory usage stable.
The file locating bug is nothing to worry about, its a known and harmless issue in the current alpha builds of NetBeans platform.
About the memory: What is it? Leaking or being garbage collected?
Regarding #3, does that error still occur? Because something similar was fixed recently
- Seems fine.
- Memory usage increasing and being collected. However it seems to have stopped now.
6: When editing translation on a Linked spatial, the save buttons don’t become enabled.
7: Not sure if this is by design, or if i want this fixed now that i’ve changed in manually, but: A Linked spatial (and children) doesn’t keep its local translation (if it had one) when being Linked.
I am busy playing with lights and it seems they do not get saved when changing any of their properties. So changing the properties in a light does not make the save icons light up. Also when changing a lights properties and doing another action that makes the save icon light up and clicking it, does not save the light properties.
Hope this helps and complements this thread.
Btw, I also tried changing the light properties in Blender and then creating the j3o, but it does not seem if all light properties are carried over, but that is more Blender Importer pipeline related I guess.
jatheron said:
I am busy playing with lights and it seems they do not get saved when changing any of their properties. So changing the properties in a light does not make the save icons light up.
Thanks, this should be fixed in svn.
Edit: Btw you should be able to save the settings you changed by shortly changing something else in the scene to light up the save button until the fix is in the update tomorrow :)
Hi Normen I did try that route but does not seem to work. I followed these steps just now to double check it.
- create box, spotlight and pointlight in blender and save to .blend file
- convert to .blend to .j3o
- right click .j3o and choose Edit in SceneComposer
- change Spot Inner Angle and Spot Outer Angle of spotlight
- set material of box to previously created j3m file
- click save icon
- right click j3o and choose Edit in SceneComposer
The original settings of the spot light is restored as it is in the .blend file, but the material setting was saved.
Am I maybe missing a step here?
Edit: okay, I went back again lol… it seems that the light’s settings were indeed saved… but… at step 7 when I reopen the j3o, they do not get loaded.
I closed and opened jmp and loaded the j3o again with Edit in SceneComposer and the saved settings still does not get loaded. Now where does the settings get loaded from?
If they don’t get loaded how you know they get saved? :?
heh, I think I might not have explained well.
I can see that the values in the Properties explorer are the same as what I changed them to, but when looking at the SceneComposer screen and also when loading the j3o via code, the light has not changed visually from its initial state (basically looks the same as in .blend file before converting to j3o).
Yeah I know this sounds really weird :X how can it remember the values from both initial settings and changed values lol
Edit: I guess the values for displaying a spot light is not loaded from the j3o, but rather from somewhere else, like its constructer?
Ah alright, so the serialization of the Lights settings is probably not working as it should, maybe @Momoko_Fan or @nehon can look into that, I will too later.
hmm, very strange, it looks particle emitters looks work in source code but not in SceneComposer. I did several tests, but the background color from particle emitter’s images is always visible, and it doesn’t matter if the image’s background color is alpha or if I set the blend mode to alpha. Also, the particle emitter is never centralized, and sometimes it doesn’t shows up anymore(maybe a serialization problem?). I got no success creating them in SceneComposer. Loading them in source code doesn’t too. Just creating by hand 
,
The mix mode is add or multiply normally.
thanks, you’re right.