As promised at GDC, we’ve got the first version of our Unity plugin ready for download. You can find it at Simul’s download page (register at http://www.simul.co/register).
It’s DirectX11, Win32 only at the moment - other API’s and platforms will follow. You will need Unity PRO, as it relies on external DLL’s.
Anyone is welcome to download and try it out - there’s a 30-day trial built-in. The plugin is accessible from the download page (just follow the “Unity Plugin” link.)
TrueSKY is a commercial system that’s in use in numerous current and upcoming games - it’s the system behind ARMA 3 and DayZ, Ubisoft and Sony are also using it, among others.
We’re not decided yet on whether we’ll put something on the Asset Store, or supply the plugin directly as with our other stuff. Right now I’d like to hear any feedback or bug reports - this is an early-access Beta, and your comments will be taken onboard as we prepare for version 1.0.
What we’ll also do is offer a big discount to the first 15 people to buy a license on early-access. Details to follow!
Our standard prices are £25000 per sku for a large team and £15000 for indies for the full SDK, including source code. The offer price is US$950 for the Unity plugin. To qualify, you just have to be an independent developer - with a budget under $200k and less than 4 full-time employees.
$950 puts it out of most indie devs price range especially compared to Silverlinings price at $100.
Is that the price for release to asset store/own site or reduced beta price for first 15.
Downloading now to test it out, would love a PM on offer for initial beta testers license.
Well - if the DLL is in Assets/Plugins/x86 that should be fine, but it depends on the other DLL’s which are in Assets\Plugins\x86\dependencies;
That’s the reason for the “Add Path” at the top - so that Windows can find these when it tries to load the render interface.
If it’s somehow still not finding them - you can try the following:
take the contents of Assets\Plugins\x86\dependencies (including all subdirectories) and copy them to the project directory (the parent directory of Assets/) - then give it a try - can you let me know if this works for you?
Hey Axel, thanks for your message! I wonder if there’s interference between the Qt version you have and the one we use for the interface. Can you try copying the “plugins” subdirectory from “ExampleProject\Assets\Plugins\x86\dependencies” into the root project (“ExampleProject”) directory and let me know what happens? If this fails, try putting the DLL’s from plugins/platforms directly into the project directory. Unity usually has this as the working directory. I’ll have a look from our end and see if we can make the search path system more robust.
Sorry for my English, but “I have installing QT” and “not I had” . I didn’t have QT before installing your package.
So I’m trying to copy the “\dependencies” directly in my root project, but it doesn’t work.
It’s the same with copying the dll directly into the root project
I forget to talk about another problem, because I thing it’s not important, but when I import your package and I load the example scene, I have no terrain.
May be it can help you to find the problem.
Although there’s terrain in the scene we didn’t export that to the package because it’s just taking up space - I don’t think it’s related, you can delete the Terrain object. We’re building a version that saves a pair of logfiles - one for UI, one for rendering - and these should tell us where it’s looking for the Qt plugins on your system - this might help track down John G’s issue also. I’ll let you know when it’s uploaded!
That looks lovely! It’s completely out of my price range as i’m not even indie, i’m not-for-profit atm, but i’ll take a look at your plugin it looks really nice! In fact it’ll be just the ticket to show off what i’m doing atm, at least for 30 days aha. Interesting you mention ubisoft and wotnot, i own a (license for a) cloud/tod product called Nuaj which was very competent given Unity was a pain for such a product at the time and the creator of Nuaj was going on to big similar things, i’d like to see them come back and make Nuaj live up to its potential now Unity is much more suitable for it.
I’d love to see how far all the simulation things are going for nebulous hard-to-render things like participating media as GPU based processing makes it possible now and we seem on the edge of a whole new world of possibility now the strength of console GPUs make such systems entirely viable in realtime, in terms of processing and financial return.
While it may be irrelevant for me, really, how do you see products like this working alongside the growing amount of PBR approaches being developed for Unity, especially given the oncoming release of Unity 5?
I’ll have a go! And come back with screenshots if i can, I do love a good bit of pimping
In the early days of trueSKY, or Simul Weather as we called it, we had no way to do raytracing in a shader, so we had to construct geometry to simulate the effect of volumetric rendering. It was pretty good for DX9-class technology, but most games developers just used static or rotating skyboxes, or 2d animated clouds - most of our customers were simulation manufacturers like FlightSafety or even Boeing. But in the DX11 era we can raytrace through media and still meet 60Hz so we’ve had a big surge of interest on console. For example:
We’re already there, really - trueSKY is all about the physics of light, and PBR allows us to connect better to the main scene, because it’s already in physical (linear) units. The question is, can displays keep up? I remember something a couple of years ago about an actual HDR monitor, but nothing since then!
Well videogaming’s very apt for HDR other than the direct practical aspects as games so often simulate being someone, in some virtual place, and their eyes being as unable to represent the full range of luminance as our own - ‘hdr’ was a special effect in games (remember having to choose between hdr and bloom? aha) and now it’s part of the workflow, and a natural product/necessity of accurate simulation.
A hdr monitor to me sounds like the idea of making a display that can represent luminance values that are painful to look at, like the sun or even reflections of the sun off cars - to me that’s when videogame and simulation lighting truly becomes realistic, but the problem there is that’s actually dangerous and could easily blind people, however that was done - So that’s a particular situation where hardware manufacturers aren’t really allowed to pursue realism, it’d be very realistic and a disaster! You probably had something more practical in mind however aha and the topic’s a bit out of my knowledge
That said, devices being able to display a broader tonality would be great, the ability to display tonality is still way behind good ole negative film’s ability to capture it, iso 100 film typically 11 stops of exposure? I think prosumer cameras only manage 8 or 9 - That’s one place where if your videogame or simulation can process a higher range than your camera can record and has the ability to display it, you can artificially get fidelity higher than you’d expect to see from any reasonably priced camera, or view anywhere other than your very fancy display. That kind of example’s a good idea of where all these things can go
Talking of such things, have you investigated the Oculus Rift and how does this go with it? I’ve noticed other volumetric systems in Unity needed to be adapted a bit to work with it. It’s something i’ll check myself sometime soon if it’s said to work well, it’s these type of effects that can look particularly amazing with such hardware
Yes - only a range that can’t actually hurt your eyes would be best. It’s of interest to us because skies generally have a high dynamic range - often much brighter than the foreground scene, or very dark at night - by a factor of hundreds or thousands compared to daytime.
Yes. We’ve not got the Unity implementation going yet but we have done a lot of work making trueSKY work well with Rift - because we render clouds etc at lower than standard resolution, we’ve had to make sure that the low-res and hi-res blending is near-perfect, because such issues really show up on VR headsets. But I think we’ve cracked it, and our mixed-resolution algorithms should be good for other applications - particle systems etc.
We’ve put up a new version of the package - 2.9.6.004 - that should help with the issues mentioned above by John G and Axel59. Let me know!
Sorry for my late answer, but I was sick last week.
I’ve tried your new package, and it is worst. Now I have the error message just when I click on “ExampleSequence” in the project window.
. I didn’t have QT before installing your package.