I like the water in particular. Still many features missing, like point lights you can move around. And I haven't given up yet on a realtime global illumination hack. I think this is mandatory today to make interior spaces interesting.
This seems a lot of work. Does it make sense to build your own renderer? My interests are more around content generation and management.
Having a custom renderer has some advantages. It makes it very easy to get any project going. Once this engine is packaged into some form of SDK, it will help that anyone can make changes, compile them and run them without any third party libraries (just the OS and OpenGL).
And then, looking at the problems you get when implementing a renderer gives you some perspective. That tiny pixel in the horizon should grow and become a fully volumetric rock. Understanding how these distant features can be produced by the shaders helps tie them down to their close-range volumetric representations.
That's incredibly bright blue water. It reminds me of Jell-O, actually, but it's a good start. It's nice to finally see water up-close in the engine.
ReplyDeleteI love the little details like the algae near the water. That's great. The mountain looks quite good too, if a little pixelated at the moment.
I see VoxelFarm as middleware and I'm confident enough to say that I believe everyone else does too. What this means is that anyone looking to use VoxelFarm is going to be looking at it as just one piece of the much bigger puzzle in real-time application development.
ReplyDeleteTo that end I really see no reason at all for you to be packaging own your homebaked renderer with the SDK. Not only is it a waste of your own time having to write and maintain it, no one but you is going to use it.
You aught to be focusing your efforts on your API and providing example demos in the leading engines out there right now (Unity, Unreal, Unigine, CryEngine, etc).
Hell, with Unreal Engine 4 recently having been open sourced you have an absolutely amazing opportunity not only to show off your product in a AAA class engine but even provide the full source code.
I agree, voxelfarm should be focusing on generating and managing voxel data and spitting out renderable components that any app sitting on top should be handling.
DeleteIf that's not the intention then I guess voxelfarm is essentially being sold as a complete solution that your application specifics simply bolt on to but for that voxelfarm will need to do a lot more than just rendering !!
I agree too, we are working on the connectors for the mainstream engines. This is a middleware tech, we do not offer a complete solution. This is where our focus is.
DeleteThe question here is if the SDK and other development products we do, like Voxel Studio, should become 100% coupled with a particular engine. It is not a trivial question.
In the past Unity 4 was not mature enough, for instance. We wanted to use features like texture arrays, but had to resort to atlases and other hacks which bring the visual quality down a notch. CryENGINE was not so simple to repackage and sublicense from the legal side if you get exposed to their source code. Their plugin system was not mature enough for us to depend on it solely as well.
And just now we got UE4. It is a very nice licensing model, but we would still need to require anyone evaluating our SDK to get a monthly subscription with Epic to be able to compile the more visual demos in our SDK. Any application in the SDK (like Voxel Studio) would become bound to Epic's license agreement. Meaning if we sold the SDK, or did a kickstarter, etc., we would need to pay Epic 5%, just because we used their rendering in our preview windows.
Last but not least, not everyone is using these engines. Many AAA studios deal with the rendering themselves, they do not use UE or CryEngine. And there are applications outside games. Not everyone working with voxels is already using a general purpose game engine or is even considering to get one.
And what about additionally coupling it with an open source engine, like Ogre or Maratis ? so you can have a "free" backend.
Delete@Anaël There is also bgfx that's just cross platform renderer: https://github.com/bkaradzic/bgfx#what-is-it
Deletethe water is a bit crappy
ReplyDeleteIt is mostly procedural sewer water
DeleteI personally prefer options. As a student I know I will end up building my own engine before I graduate, but I don't know if I will keep it when I am done. As appealing as the UE4 engine is, there might be aspects that I feel I can do better with my own engine that is focused for what I need. In that case it would be helpful to have a render built in just in case there are periods of time that I need it- that being said, it would also be very helpful to have the ability to jump right into the UE4 engine if that is the direction I choose to go. Doing both would be a great deal more work for you, but it might help not to segregate some potential user base. But you already knew all that, so I suppose this post is sort of pointless.
ReplyDeletePersonally I think all your efforts should be spent on the VF Engine, let the end user worry about the rendering!
ReplyDeleteI will disregard your comment because I know you come from Landmark :)
DeleteI think a custom gfx engine also adds to the overall value of your tech in case of a buy-out offer. If you have the time and resources building your own engine is definitely a worthwhile investment.
ReplyDeleteYou've put an awful lot of your own time and effort (and I'm sure blood, sweat, and tears) into the Voxel Farm technology and come an awful long way. It's now integrated in a couple of platforms (both middleware, and proprietary) and things are looking great. Who is it for us to say you shouldn't develop the engine tech with it? Who knows where working with an engine built to custom fit the tech will take you, what opportunities and realisations it will yield. Enjoy yourself I say. :)
ReplyDeleteOn a more personal note; when developing with novel/disruptive technology I can see a case where more a conventional engine tech framework could be prohibitive to it's evolution and not a good fit. Whether this is the case with yours I couldn't comment.
Sam
I know this is a late reply, and maybe a naive one, but I think it's a business decision more than a technical one. Technically, in the code, you should never couple your code to a renderer. Business-wise, having a renderer included with your tools sounds like a good idea, if in exchange you can get support, a voice in future development of the renderer, and/or access to their existing customer base. If all goes well, this may convince other renderer developers to compete to better support VoxelFarm and voxels in general.
ReplyDeleteIf you do include your own renderer, I think you could avoid making it a separable product (licensed just for the tools, not for the engine). I could see that being worth it if you can demonstrate something no existing renderer can deliver, to convince them a feature is worth implementing.