tool
Credits: Thanks to vux for DX11 and to unc for cube texture shader. Thanks to http://www.emdl.eu/ for the group they are.
This pack provides the basic building blocks to create immersive content for any dome type architecture, similar to dome-master-full-dome.
It comes with the following modules
Dome: allows quick adoption of the setup to your specific dome type
DomeMaster: creates a valid DomeMaster output for your setup
DomeImmersion: allows to move the Point of Immersion in realtime
All content can be placed in a Sandbox, independent of the rest of the engine and the specific dome setup. My hope is that this will foster independence of content from the specific dome you are working at.
As a bonus it comes with some neat personal 360° panoramas, same CC4.0 license applies
Older Revisions
anonymous user login
~6d ago
~13d ago
~13d ago
~14d ago
~27d ago
~1mth ago
~1mth ago
~1mth ago
~2mth ago
~2mth ago
Thanks for sharing velcrome! Small bugreport: there is some 'Comic Sans' in the mainpatch ;)
that's intentional, just to remind you to consider children when setting the default height :)
Hahaaa! Still remember the early days of VVVV where it opened with a splash image of movie raings for ALL AGES.. how can I forget :))
Hi
I just notice the license and notice the little nc and sa. How would one go about licensing this for commercial use?
I don't actually need this for a commercial project, but I was just wondering about it, I remember a thread some years ago about the license of contributions and thought it might be problematic in some instances.
Perhaps an option to set a license when you make a contribution would make some kind of sense.
Just wondering
Sune
Glad you brought that up, because it might need some explaining to not seem unreasonable.
intolight is a small studio and cannot approach open source in a similar way as, say intel (with opencv) or google (with go), etc. Besides our past references of our work, the only thing that will provide food into our mouths is our know-how, and hence our code. Many other studios probably agree, because a lot of brilliant vvvv patches never see the light of this website, just to protect this know-how from "being abused by other companies".
However, in good vvvv spirit we want to share this knowledge with the community of vvvv and the Domies all over the world. But this does not mean that we are cool if someone else is earning money with our work and we go hungry all the while.
So the default license is open to about everything related to Free Sharing, but it requires you to
I agree that this seems like a show stopper for some use cases (especially commercial ones), but mind you, this is only the default license. If you think, that your use case cannot be done within these boundaries, then simply contact the copyright holder at license (at) intolight.de and tell us about your project.
Don't worry, we will not stop you making money with the help of these patches, but we want either a slice of it or some in-kind appreciation. For a contribution to the kit we might offer you a non-transferable commercial license, for a flattr-donation you might not be required to mention us in your work, etc.
Also we want to reimburse people that have contributed with their work (vux, unc) from any revenue we generate by applying this license model.
So yeah, the default license is made for all that want to learn, teach, research, entertain or make art just for the fun of it. If your endevour is beyond that scope, simply email us and tell us about idea. We don't bite and it is our declared goal to help both the fulldome and vvvv ecosystems to prosper and flourish.
It sounds good and I totally understand the reasoning behind it. I do however see a potential problem(as with all these cases about licenses everything is potential problems and I guess that is why you make licenses in the first place).
CC is originally made for music and similar creative output. Where a work you have created can be released for other to remix if they only share alike. what the musician is not obligated to share though is his/her instrument.
I could imagine me being asked to make a performance in a dome, since this contribution is made it would be the logical step to use this to modify my performance patch to work in a dome. I have no problem releasing my output under a CC license, but in this case I would need to release my "instrument", which is what gives my visuals my "distinct look". since the license says SA.
Of course if I improve on the Dome Tool itself, it makes sense, but I don't necessarily think that the patching I use to create the creative output should be CC as well... a bit like releasing a movie projector where everything you show on it becomes CC.
Is this the case or am I interpreting the license the wrong way?
In other words, are you sure you mean the SA part?
Or does the SA part only apply to changes made to the Dome contribution itself or?
Please read this note positively, I am all for open licenses, but the right ind for the right place.
Sune
Thanks for the questions, it helps me to relate. Licensing is a touchy subject, and we should consider a different thread for discussing broader implications.
But to your questions:
I have the notion that CreativeCommons ShareAlike does not force you to publish your instrument, it only wants you to use the same CC again if you choose to give your instrument to anybody else or make a copy to someone else's system. SA pinches here: You can only give it away to all, not to just one.
What I gather from your feedback is the need for a different license for content. Maybe I can exempt the Content-Folder and open that up for anything-goes, as defined in its folder, or default to
Would that be acceptable?
And as I said before, for all the the grey areas with money or secrecy involved, just head over to license (at) intolight.de to negotiate fair terms beyond this license
Hi, thanks for sharing, any idea about using MRE(Emeshe) inside of Dome?
mmh, not sure. the core of the dome pipeline is a cubemap texture (aka Full Sphere), and emeshe works with plain 2d textures to do its deferred shader magic. it might be possible to rewrite the shaders to use cubemaps instead, and keep using the material definitions and all the rest of emeshe.
Thanks, at the moment it looks a bit complicated to pull it out right and definitely is out of my writing skills.
My other question is how to deal with alias like problem inside of the dome, I keep getting this saw like effect on the lines and borders. Tried to change resolution settings but no luck atm. https://dl.dropboxusercontent.com/u/13211363/DomeAntialiasing.v4p
yes, Antialiasing settings are missing in the dx11 cubemap renderer.
in real life, this does not matter much, because after projecting into a spherical dome everything will look different anyway. if aliasing still prevails, try to simply oversampling (setting the resolution of the intermediate cube texture a little higher than necessary)