I'm currently using Direct X 11 for my procedural world/MMO project. I've tried to find a freeish game engine or simply graphics engine that supports 64 bit coordinates (CPU side), but apparently there is no such animal. Right now my investment in Direct X is very small as the vast majorly of the code is straight C++ and the graphics is isolated into an interface class. However now I'm going get more into the GPU stuff and I was wondering if it would be better to switch to something else that would give the program better portability. I was leaning towards Vulkan for no other reason than it seems to be all the rage (ha, ha), but I wanted to get some opinions from folks with more GPU programming experience.
Vulkan? OpenGL? What........?
Huh? No engine with 64bit coordinates CPU side? I hardly belief this. I do this with my game engine and I don't think I'm unique in that department.
2 hours ago, Gnollrunner said:I've tried to find a freeish game engine or simply graphics engine that supports 64 bit coordinates (CPU side), but apparently there is no such animal.
IIRC CryEngine & Lumberyard do this by default?
2 hours ago, Gnollrunner said:Right now my investment in Direct X is very small as the vast majorly of the code is straight C++ and the graphics is isolated into an interface class. However now I'm going get more into the GPU stuff and I was wondering if it would be better to switch to something else that would give the program better portability. I was leaning towards Vulkan for no other reason than it seems to be all the rage (ha, ha), but I wanted to get some opinions from folks with more GPU programming experience.
If you want portability in general, then you'll have to use more than one GPU API You can defer this decision to a future time by keeping a strong decoupling layer between higher level rendering algorithms (scenes, shadows, lights, models, materials) and platform-specific (D3D/VK/etc) implementation details.
If by "portability" you mean "support Windows and Linux", then yeah, VK/GL can solve that particular problem... but if you mean "support Windows and game consoles", then VK/GL aren't very helpful ?
D3D11 is probably the most stable GPU programming environment due to it being used by the majority of games for the last decade, so it's a great choice to use as your "primary" API if you do end up using more than one... You can also run D3D11 on Linux (Wine) via https://github.com/doitsujin/dxvk if you want.
38 minutes ago, RPTD said:Huh? No engine with 64bit coordinates CPU side? I hardly belief this. I do this with my game engine and I don't think I'm unique in that department.
If you know of any that are available, I'd be happy to hear about them. I've asked around quite a bit on various sites.
19 minutes ago, Hodgman said:IIRC CryEngine & Lumberyard do this by default?
From what I understand (and I may be wrong) only the Start Citizen modified version of CryEngine supports this and of course that's proprietary. I checked into Lumberyard before and I saw some banter about it but nothing that said it was implemented yet. In fact just about every major engine has some forum posts where a few people have asked for it. The only one which defiantly has it that I found is UNIGINE and that's kind of pricey.
I guess you might be right. It's better to defer this stuff until later.
2 hours ago, Gnollrunner said:From what I understand (and I may be wrong) only the Start Citizen modified version of CryEngine supports this and of course that's proprietary. I checked into Lumberyard before and I saw some banter about it but nothing that said it was implemented yet. In fact just about every major engine has some forum posts where a few people have asked for it. The only one which defiantly has it that I found is UNIGINE and that's kind of pricey.
I guess you might be right. It's better to defer this stuff until later.
I guess then I need to hurry up putting those finishing touches in place
When you say game engine / graphics engine, what functionality exactly do you need?
It is probably a pretty low priority for most general purpose engines, as most people don't need 64 bit coordinates, and many of those that think they do can usually get by using a different method (moving origin etc).
It's unlikely to be necessary for e.g. character animation / skinning, particle effects...
So if you are making a general purpose engine, you would presumably either:
- Make all 3d math 64 bit and make 99.9% of people pay the cost for something they don't use
- Support more than 1 precision throughout, which could potentially multiply complexity and bug potential unless done very carefully
If it is just CPU side, can't you use your own 64 bit classes, then downsample to 32 bit for rendering?
Dave Eberly's classes (https://www.geometrictools.com/) are usually designed to be able to change the bit depth if I remember right. Most of mine are written similar way with templates so it is easy to change whether a float is 32 or 64 bit.
Without more information is hard to say more.
API wise for multiplatform I bow to other's knowledge, but personally I'd be strongly tempted to use a third party abstraction layer like diligent engine or bgfx if at all possible. As Hodgman says it depends very much on what you mean by multiplatform. There's consoles, and then there's the wild west of OpenGLES on mobiles.
1 hour ago, lawnjelly said:When you say game engine / graphics engine, what functionality exactly do you need?
Mostly graphics, animation, physics..... what have you. I can work around what's missing. I'm just trying to get out of writing everything myself.
QuoteIt is probably a pretty low priority for most general purpose engines, as most people don't need 64 bit coordinates, and many of those that think they do can usually get by using a different method (moving origin etc).
While this may be true, I do need it and other apps that have needed it like Start Citizen and Dual Universe are using custom or pricey engines that support it. I need to be able to go from orbit to the surface and messing around with all sorts of offsets to handle this makes things more complex. One issue is seams that appear in between chunks if things don't match up perfectly.
QuoteIt's unlikely to be necessary for e.g. character animation / skinning, particle effects..
Yes not for those things but for large terrain it's highly desirable.
QuoteSupport more than 1 precision throughout, which could potentially multiply complexity and bug potential unless done very carefully
I support more than 1 precision now for many things. My matrix and quarternion classes are templates.
QuoteIf it is just CPU side, can't you use your own 64 bit classes, then downsample to 32 bit for rendering?
Yes I do this now. Everyone that has to support large terrain does this and that probably won't change. However keeping track of things on the CPU and server side is sill much easier and faster with 64bits. CPU double precision is not particularly slow as it is on GPUs.