I didn't want to talk about it in FFF so I don't make people hyped accidentaly ... My big goal is to make streaming from HDD work. For that to work, virtual atlas needs to be saved on disk (there's no way to stream from PNG spritesheets, efficiently), but given that practically majority of people can fit all sprites in VRAM anyway, we probably won't distribute pre-baked virtual atlas, and streaming will be optional. So user computers would build atlases anyway, as they do now. If we decide to distribute pre-baked virtual atlas (or some metadata to generate more efficiently packed atlas), the game would generate atlases for each mod, which would be appended to virtual texture coordinate space of main mega-atlas. So no additional work for modders in any scenario.
EDIT: When I wrote the first line, I though about Xterminator's FFF discussion video ... I didn't think Klonan will leave it in
That's an interesting idea. More on this topinc in the future, though.
Procedural wires are in our backlog (not very high priority at the moment though). We also would like to try to do smoke procedurally, but there we might run into an issue of reopening work that was considered finished.Oktokolo wrote: ↑Fri Oct 12, 2018 7:15 pmI am no GPU coder, but would expect stuff like smoke (maybe also clouds) to be faster if rendered by a procedural shader in the GPU instead of layering tons of bitmaps above each other. That stuff probably is mathematically generated (instead of modelled or painted by hand) already. There are also almost always clusters of many smoke sources in a factory (steam power plants, smelter arrays...).
The smoke shader would probable be able to use a single list or bitmap of smoke source locations and state. It would render all the smoke in a single pass, so that it would cause only a single overdraw per scene pixel.
Maybe, power/circuit cables could also be drawn procedurally for the full scene at once. But they probably do not cause much overdraw anyway.
Yeah, I would prefer "animation and variation quality" options to current low and very-low sprite quality options. (Btw. I am not sure how many animations are 60 FPS but I would say not many, there might be some 40 FPS ones, most 30 or less FPS).Oktokolo wrote: ↑Fri Oct 12, 2018 7:15 pmIf for some reason, VRAM use ever becomes an issue, you could give players the option to only use any 2nd, 3rd or 4th frame of each animation, so that only animation FPS suffers instead of having the entire scene FPS drop. That way, animations would lag but player movement would still be butter smooth. Optimally the player could also select groups of stuff to have the full or at least half the animation frames (so they would still get 30 FPS for them). One obvious exemption group would be belts another one inserters. But apart from that i don't know what groups would make sense.