When a non flattened object comes into view, the engine will suffer a hick-up. Not really shocking since textures etc associated with that object may be loading for the first time. What gets me is this; when that same object goes out of view and comes back into view, the same hick-up reoccurs…over and over again.
The last old engine source code I used before P3D (years ago), did not have such a hick-up issue because texture loads were controlled by you and you loaded those textures at level start (normally) and those textures kept their scope around until you unloaded them. Texels that could not be held in video memory were placed into RAM, which the engine used as extra video memory (smart procedure).
The hick-ups in P3D gives the impression of texture data being dumped once an object is out of view and then reloaded once it comes back into view. Once again, non flattened objects so far; I haven’t really seen a whole lot of this awkward behavior with static geometry (or maybe I haven’t been paying attention enough).
Would be nice if textures could be pre-loaded at level start, but I’m guessing the scene graph rendering pipline prohibits that.
Any ideas of why the hick-ups are occurring constantly with moving objects going out of view and back in?
(not with my current project but in general since I have been working with P3D)
I haven’t seen this behavior. Generally, the “hiccup” only happens the first time an object is rendered, and doesn’t need to happen on subsequent times.
By default, we leave the texture memory management to OpenGL (though there are options to override this if you enable them, but you would have to know about these options to do this). This means that the OpenGL layer will be responsible for keeping and reloading textures that have been evicted for size. So I guess you could be experiencing these kinds of hiccups if your model has too-large textures for your graphics card, and your driver were doing a bad job of texture management; but in this case it’s out of Panda’s control.
You might also be experiencing these kinds of hiccups if you explicitly set some of Panda’s cache settings to 0 or very small.
If you’re not doing any of that, I have no idea why you’d see this behavior. Can you provide a code snippet that demonstrates this?
5000 is the default and is usually large enough to keep a model in memory while it is still relevant.
The texture cache is controlled by:
graphics-memory-limit -1
-1 is the default and means that Panda does not manage the texture cache, but leaves this entirely to your driver. If you put a specific value, it would be in bytes so would be a large value like 4294967296 or something. Usually there’s no reason to put a specific value unless you really need to aggressively manage texture memory or you think your driver sucks at this.
There are other, more advanced controls for managing memory very precisely, for doing things like streaming models or textures from disk in a child thread while you continue to render an incomplete model in the main thread, but I really doubt you want to be getting into that level of control.
Incidentally, there are also controls for managing the initial hiccup on first display of a model (you can preload the model with root.prepareScene()), but that’s not the problem you’re reporting.
Does P3D load a new texture(s)/atlas every time an instance of an object class is created? I noticed when the same object class creates a(n) instance and that instance enters the camera view for the first time, the hick-up happens. That’s why I thought it was the same object before, but it was just a twin instance causing the issue.
I assumed P3D used the same textures for identicle instances; guess not. So a P3D RTS style war game with 1000 soilders of the same instance kind on screen would end in utter fps destruction because of the same textures being loaded multiple times…?
Creating installations for P3D made games under windows (tested vista and 7) causes an error on game start which states something about not being able to find or open the main.exe.log file. I know errors will write to this file if errors are present, but I’m talking about an error free exe file. Again, this only happens when an installation is made but not when running the exe file from a folder holding all the content.
What could possibly be happening during the installation creation process and P3D apps? Why no issues when running a non installed exe?
It depends on how you create the new instance. If you just do loader.loadModel() of the same filename, then the new instance will have the same texture objects and the same geometry objects as your previous instances, so there will be no hiccup–unless you have previously done something like ModelPool.release() or TexturePool.garbageCollect() or any of those related things designed to free up memory, which will force Panda to create new objects for your new instance instead of re-using existing objects.
If you are creating the instance yourself by creating new GeomVertexData() and new Texture() objects and populating them with Python code, of course these will be competely new instances that will need to be loaded on the graphics card.
If you are using the shader generator with model.setShaderAuto(), it is possible that some new configurations of state in your new instance will require a new shader to be generated and compiled, which will also cause a hiccup.
(sigh… ) You have to forgive me… First time in dealing with an engine which regenerates a shader so often (and for identical instances).
Now that I know this happens when creating multiple instances of an object class… My logic for object class creation has changed; for P3D. I assumed P3D was programmed to understand that an instance coming from the same object class would be identical and therefor re-use resources from a previous instance (like the past engine I worked with).
Feels like I’m in a dog fight with a graphic engine and the engine is “tearing me a new one.”
Oh well, at least I know of this and already figured out a new class logic to avoid this in the future. I just hope I don’t run into a “garbage collect” issue using the new logic.
The good thing about the commercial title under my lead, it has no need for multiple instances of the same class.
“Jeezus!!!” What is going on with Software Developers now and days!? I think I found the problem causing installation errors; I tried multiple software installation creation programs and all of them did the same stupid thing… Any directory with 0 bytes, was not included in the installation!!!
Um… Excuse me, just because a directory is empty to begin with doesn’t mean the application being installed isn’t going to populate it later on.
It is bad practice to write files into the install directory of your game. On Windows this will require the game to be run with admin rights for anyone who installs to the usual Program Files directory. Your game should take care of creating directories inside the user account folder at runtime.
In any case, it is good practice to make sure a directory exists before trying to write a file there. You never know when a user might think it is OK to delete their save game directory to reset the game for example.
) You have to forgive me… First time in dealing with an engine which regenerates a shader so often (and for identical instances).
