|
Post by sbdjazz on Mar 18, 2017 3:10:50 GMT
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 TinSoldier on Mar 18, 2017 3:26:19 GMT
See the demo project called WebDownloadDemo.3dr mentioned in the help files.
Test it thoroughly because 3drad pause's the project while it process's file loading functions.
|
|
|
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...
|
|
|
Post by indiedev on Mar 19, 2017 3:37:42 GMT
if you have only 2 skins just use show/hide on each, does not freeze as above.
|
|
|
Post by sbdjazz on Mar 19, 2017 4:07:27 GMT
Thanks guys, I got it.
|
|
hawk
Full Member
Posts: 69
|
Post by hawk on Mar 20, 2017 3:43:23 GMT
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 indiedev on Mar 20, 2017 9:22:31 GMT
i can understand refreshing rigids causing Fast-FWD, but if skins cause it too you're basically saying iobjectrefresh is mostly unusable then?
|
|
|
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.
|
|
|
Post by sbdjazz on Mar 20, 2017 16:36:28 GMT
OK
|
|
hawk
Full Member
Posts: 69
|
Post by hawk on Apr 5, 2017 9:20:35 GMT
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: Method | Start up time | Selection Time | My Naive Lazy Loader | Fast | Always Slow | My Load all first loader | Slow | Always Fast | Supers Caching Lazy loader | Fast | 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)
|
|
|
Post by indiedev on Apr 6, 2017 14:50:11 GMT
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.
|
|