Dynamic combination

a guest Mar 4th, 2019 118 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. if it's dynamically built it's fine because enable / disable can invalidate the combined mesh and request a recalculation.. something like this maybe:
  2. 1. you load a cell and at first you don't have any precombined meshes, it requests a recalculation of cell (at this point we use regular meshes for drawing that aren't combined yet, this results in many draw calls), this request to recalculate is pushed on another thread so your main render thread is not affected by this (it would cause stutter)
  3. 2. another thread is combining the meshes that it can
  4. 3. when the other thread is finished the combined mesh groups are pushed back to the main thread and the meshes that are part of the combined meshes get culled away and not drawn anymore, instead we use the combined meshes now
  5. 4. if something gets disabled or enabled and it's part of the combined mesh then the whole combined mesh gets invalidated and a new request is pushed to the other thread while we keep using the uncombined meshes until the other thread finishes
  6. 5. if the cell is unloaded while the other thread is calculating combined meshes then the task is aborted
  7. RalgorToday at 16:57
  8. You could do that if objects are moved too.
  9. You just have to be careful and don't combine too much together so things are constantly invalidated.
  10. meh321Today at 16:58
  11. yes, but it would be better to avoid including any moved objects in there in the first place
  12. but yes possible if some object moves unexpectedly it can also invalidate
  13. JohnToday at 16:58
  14. (be careful you don't end up with GTA4 entire map is 1 file)
  15. :GWqlabsFeelsFunnyMan:
  16. meh321Today at 16:58
  17. it's like skyrim, it's actually possible to move the terrain tiles around in game, but it's not expected
  18. RalgorToday at 17:00
  19. ALso, once a static is moved or enabled/disabled, you could flag it not to be included in the next precombine
  20. So if it happens again, no problem.
  21. meh321Today at 17:00
  22. good idea
  23. RalgorToday at 17:00
  24. You could also cache these precombines.
  25. with those flags
  26. So repeated cell loads just load the cached versions
  27. You'd just have to know when to invalidate the cache on load
  28. JohnToday at 17:00
  29. Eventually the game would have precomined never moving meshes cached
  30. meh321Today at 17:00
  31. mmhm you'd have to keep it in memory, possible but dno if it's worth it ?
  32. JohnToday at 17:00
  33. Dynamically.
  34. RalgorToday at 17:01
  35. Yup
  36. JohnToday at 17:01
  37. Any way to store the cache to disk maybe?
  38. RalgorToday at 17:01
  39. I wouldn't bother with caching at first. Only if the system works out
  40. meh321Today at 17:01
  41. i think it won't be worth it, the combine will not take long on the other thread, humans can't even perceive it most likely
  42. RalgorToday at 17:01
  43. Right. Don't optimize until you have proof you need it.
  44. JohnToday at 17:01
  45. Well, no matter, it seems that system would work .
  46. Y'alls is smart
  47. :pepe:
  48. RalgorToday at 17:02
  49. @AnyOldName3 meh321 came up with your answer. :smile:
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand