Is there a way to change a skin mesh or load a different skinmesh using script? Suppose I have only one skin mesh object, I want to change it to a different skinmesh while playing the game. Some what like car customizations in NFS Underground 2. Thanks in advanced.
Post by Power Supersport on Mar 18, 2017 8:14:48 GMT
Use iObjectRefresh(OBJ_X, path) function, but keep in mind that the editor freezes during the loading...
The OBJ_X is the object you change, and the path is a string with the file path of the new skinmesh (000_mesh.x)... Note that it's not necessary for the file to be called 000_mesh, it could be anything, but it has to be a .x mesh file...
I second super on this one, changing skin meshes by loading them at runtime freezes the game, and compiled projects have a fastforward effect after its done. For the purpose of car customization I suggest you load all your skin meshes first and just show/hide them since loading larger models take more time
Post by Power Supersport on Mar 20, 2017 13:20:36 GMT
People, refreshing is much better than preloading all skinmeshes and doing a show/hide. Simply because loading in 3D rad is insanely slow. If you manage to cleverly use the refresh function, you might be able to properly optimize both the loading time and the overall experience.
What I can recommend is using an empty skinmesh for every car and refresh it when the player switches to it. Make a script to remember that the skinmesh is loaded and to prevent the skinmesh from refreshing over and over again when selected. That way you don't need to load all cars if they won't be seen at all.
i can understand refreshing rigids causing Fast-FWD, but if skins cause it too you're basically saying iobjectrefresh is mostly unusable then?
I made a test game a while back which naively loaded skinmeshes off the file system only when cycled thru in a menu, the models were pretty simple and there weren't many of them, switching in the editor just froze the game until the mesh was loaded (1 second on my machine) so I thought I could live with that. Compiled games were so different, the orbit cam would zoom around after the game froze to load something
Super's idea of caching the models once loaded is smart, but would still have the problem of scrolling thru the list the first time would be slow, after that, it would be instant.
So in comparison:
Start up time
My Naive Lazy Loader
My Load all first loader
Supers Caching Lazy loader
Starts off slow, ends up fast
I think you can make it consistent like this: Use supers method, when you cycle through the parts, don't load them just show a picture. the user can choose to try it on, if chosen, put a loading screen or something creative like a cloth gets thrown over the car, or the part is surrounded in smoke, show this for a set amount of time, and in that time load the model. Even if the model is loaded show that effect for that set amount of time (as short as possible not to bore the player)
ok, after thinking about it, i now understand the Fast-FWD effect [as have not tried object refresh yet] if the game pauses during that, then physics calculations have to catch up, so the longer the pause, the longer the F-FWD effect.
your results also suggest that the orbit cam is physics based, so F-FWD likely won't affect still cams if player is also still.