New dithering method dropped
I call it Surface-Stable Fractal Dithering and I've released it as open source along with this explainer video of how it works.
Explainer video:
https://www.youtube.com/watch?v=HPqGaIMVuLs
Source repository:
https://github.com/runevision/Dither3D
[#]gamedev #vfx
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
Several people have suggested I write a paper / white paper / Siggraph submission about Surface-Stable Fractal Dithering. But I haven't written in academic style since my Master's thesis 15 years ago, and don't really want to either.
In case anyone with experience writing such papers might be interested in writing a paper about Surface-Stable Fractal Dithering with me as consultant and co-author (if such an arrangement is a thing), I'd be up for discussing that.
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
@runevision You don't actually have to write in academic style, as long as you clearly explain what it is you're solving, how you're solving it, and what's interesting about your particular approach.
=> More informations about this toot | More toots from StompyRobot@mastodon.gamedev.place
@StompyRobot Are there any papers you could point me to as reference/examples of what you mean by not having to write in an academic style? I thought for example that it's mandatory to have a survey of existing work, which means reading and referencing other academic papers, which in itself is a very academic writing thing to do.
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
@runevision @StompyRobot just watched the video and came here to suggest you publish this, only to find others had suggested the same thing!
I would suggest you look into submitting to #JCGT. JCGT (https://jcgt.org/index.html) is aimed to be much more of a practitioners' journal than an academic one. It's meant for modest, practical contributions that clearly work. It values reproducibility highly, but unlike SIGGRAPH, it doesn’t expect comparisons to 10 different techniques (just the most relevant baseline). Think tech blog post++ in archival form. See bullet points here: https://jcgt.org/write.html.
=> More informations about this toot | More toots from wjarosz@mathstodon.xyz
This is the review form we use, which gives reviewers (and authors) a sense of how JCGT papers are evaluated for publication. https://jcgt.org/files/review-form.txt
=> More informations about this toot | More toots from wjarosz@mathstodon.xyz
@wjarosz Thanks for the suggestion. It looks nice, but one snag is that my source code can't count for their submission. "Any source code and data provided must be under a non-restrictive Open Source license (e.g., MIT, BSD) so that it is directly usable by readers. Papers with usable source code are much more likely to be accepted." Mine is licensed under Mozilla Public License 2.0 which has some minor restrictions.
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
@wjarosz I use the MPL license because it's permissive enough that people can use the work in their commercial and proprietary products if they want, but if they make improvements to the specific thing I shared, they just need to share their improvements too. To me, this is a modest and fair ask. Is there anyone from the JCGT editorial board or advisory board I could ask about whether the MPL license would be acceptable for the source code of a submission? Is it something you could answer?
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
@runevision @wjarosz I think you should stick with your principles. If JCGT doesn’t like it, it’s their loss.
=> More informations about this toot | More toots from castano@mastodon.gamedev.place
@castano @wjarosz Cheers, I will. I just want to hear if it could still be acceptable for them, or not.
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
@runevision @wjarosz you are pre-supposing they don't like the MPL, which seems like a kind of self-sabotage?
MPL is plenty free and unrestricted enough IMO, so you could just submit. What's the worst that could happen? You already did all the work...
=> More informations about this toot | More toots from StompyRobot@mastodon.gamedev.place
@StompyRobot @wjarosz I’m not pre-supposing. MPL is open but not non-restrictive so does not live up to their stated criteria. It would require a dispensation, or they should clarify their criteria otherwise.
I’ve written neither paper nor abstract. I’m actually not clear on whether the expectation is that a paper has already been written when submitting an abstract.
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
@runevision @wjarosz They didn't say it was a hard rule, either, only a preference. If it were me I would submit first, and discuss later if they make an issue of it. Their stated reason is compatible with MPL: anyone can drop the code into their game without worry of "infection."
=> More informations about this toot | More toots from StompyRobot@mastodon.gamedev.place
@runevision @wjarosz but, you are not me :-)
On a related note, did you look into whether MIP map hardware could help implement this mechanism? It feels tantalizingly close.
=> More informations about this toot | More toots from StompyRobot@mastodon.gamedev.place
@StompyRobot @wjarosz There’s a few notes on mipmaps near the bottom in an FAQ I wrote here:
https://github.com/runevision/Dither3D/discussions/12
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
I didn't want to say anything earlier, but is the spelling mistake intended?
=> More informations about this toot | More toots from thendrix@social.hendrixgames.com
@thendrix @StompyRobot @wjarosz I did not intent any spelling mistake, no. Could you point out which it is?
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
The English is frequently asked questions. No worries, I thought maybe it was an in-joke.
=> More informations about this toot | More toots from thendrix@social.hendrixgames.com
@thendrix @StompyRobot @wjarosz Thanks! I must have written "frequency" too many times lately.
=> More informations about this toot | More toots from runevision@mastodon.gamedev.place
@runevision @wjarosz hmm. Not sure I agree with "Mipmaps cannot be used to produce fractal-like detail that keeps being crisp at any zoom level."
I'll reread the original derivation and see if I can find something I'm missing.
=> More informations about this toot | More toots from StompyRobot@mastodon.gamedev.place This content has been proxied by September (ba2dc).Proxy Information
text/gemini