Is glow a real time gi system with baked lightmaps so each lights indirect lighting is baked into the lightmap and then they are drawn additively so you can turn on/off individual lights and for the dynamic object does it use what data voxels or probes?
-what to expect from drawing performance is it optimized?
-what to expect asset pipeline and materials like pbr material editor and visual feedback in real time
-what to expect entity system performance. components overhead on script language. transform updating speed
-what to expect physic engine performance. speed of the engine and speed of transferring position data to the transforms
-what to expect 2d performance. does 2d use 3d transforms for objects what cause unwante overhead
-what to expect can I disable things i dont want to use like network and others
-what to expect video playing and animatin system for cutscene
-what to expect model decimation for distant view/create optimized model for optimization of details
-what to expect can I using typescript and c# in the same object and can they communicate each other
-does it have rain system wiuth rain occlusion objects
-does it also have occlusion culling to not draw occluded objects
Hi, welcome to Atomic. Your post formatting is broken/weird. I guess you had a hard time with the editor and the list tool. @JoshEngebretson if you gimme permission I could fix/format posts like this when I see them.
I only have answers to some of your questions, for the other ones you’ll have to wait somebody else to reply, especially regarding Glow since I didn’t use it yet and it’s still a WIP. Probably @JoshEngebretson will kindly answer those for you very soon though.
The scenegraph is quite performant and afaik optimized for rt usage, it’s not a naive implementation although it’s also not the most sophisticated one around, but I believe simplicity in this case is one of the best kinds of ‘optimizations’ you could have. You shouldn’t have problems with that. Scripting overhead exists, for JS Atomic uses duktape what I can’t comment much about, and for C# either .NET Core or Mono (a recent iteration) which are quite fast although obviously there’s marshalling and the cost of running a VM, but again, you shouldn’t have problems and you can expect Atomic to perform just as well or better than the competition here.
Atomic uses Bullet for 3D physics and Box2D for 2D. They’re both well-known physics engines battle-tested in the industry including in many AAA games. While they’re not the fastest ones around they should be enough for almost any necessity, both the libs and the integration are native so performance is quite good, I don’t know if Bullet provides some kind of bandwidth optimization (like active transforms) but it has ‘sleeping’ and certainly takes full advantage of the scenegraph optimization anyway (no naive updates and such).
It’s certainly on the roadmap. Nothing keeps you from doing that right now though, it’s just not as easy as @JoshEngebretson wants it to be, but if your game is not a small project, then stripping out the stuff you don’t want for release isn’t going to be significant. For very small games the effort could be proportionally considerable though depending on how much you’re going to cut out. @JoshEngebretson wants Atomic to be fully modular in the future.
I’m not sure if there’s support for video, but in the absolute worst case I guess you could play them through CEF what would allow you to play some modern formats like webm and h265 I believe.
There’s no easy animation system in place at the moment, but you can animate stuff using an external editor, I don’t know if things like cameras are imported, but in any case you could animate generic objects, import them as nodes and attach a camera to them in Atomic.
Atomic does have LOD support built-in, but afaik there’s no automatic LOD generation, however, you can do the LODs in the 3D package you’re using. It would be nice to have LOD generation, but that’s somewhat complex, specially for skinned meshes, so maybe using a 3rd party service could also be an option. There was a discussion on Gitter about using the OGRE mesh simplification algorithm but I don’t think there’s anything concrete yet.
I don’t think that’s ever going to be possible in a seamless way. The only way I can think of to do that is cross compiling all the scripts in a compatible language, but I doubt that’s gonna happen as it generally doesn’t produce good results. We certainly are going to provide events you can use to pass simple data around but it’s not going to be seamless so ideally you’ll want to stick to a single language for your entire project.
Nope, and I guess this is out of the engine scope.
Yes, there is occlusion culling (at least) for terrains. Not sure if you can include arbitrary occluders but in any case the terrain does occlude any object ‘behind’ it (AABB proj).
EDIT: Just noticed that quoting totally broke the list numbering :(… Discourse really needs to put some work on the list thing
Sorry guys, my bandwidth is a bit limited right now on discussing Atomic “in the large”.
What I can say is that Atomic technology is geared for production, and is being used by a number of companies to ship both games and serious applications. I am looking forward to having more showcase content within the next months
Atomic is also a great chassis for all kinds of R&D, including graphics, physics, etc… and a fun codebase, once you know how to drive it. The later we need to work on, so it is more obvious exactly where to find the gas pedal
As for what to expect, Atomic is more of a technology partner than a technology provider… big difference, and with Atomic you #OwnTheSource
@Stinky You can bake environment maps now, have a look at the Cubemap example included with the editor download. We won’t have GPU hungry realtime GI anytime soon, though Glow does a really nice job with baked GI, which doesn’t drain batteries in 10 minutes There are some folks discussing leveling up the editor PBR support, maybe spin up a specific feature thread on what you are looking for… and I’d suggest linking it in Atomic Chat
I really don’t get why these advanced photo-realistic rendering features are so important for indies. While having them is a nice addition, with very few notable exceptions successful indie games can’t afford to populate scenes with the high-quality and highly detailed assets necessary to extract everything these technologies offer.
Heck, even LOD meshes is a nightmare in most of the games I’ve worked (some not so indie), especially if you’re planning to use LOD1 or even LOD2 for the first level in some settings, what requires them to be hand-made. Then there’s shader LOD too… these things take a lot of effort and most people don’t even realize they’re there (if you do it right :P).
That’s the problem with PBR and going for realism, you put way too much work for way too little benefit, and it only gets worse as we add more realism to it, it takes more time to clip the stalk of the cherry on the cake than to make the cake itself, AAA studios can take the hit but indies can’t. Efforts go up while visible benefits go down; you have to find a sensible compromise and draw a line somewhere, and in my opinion you should draw that line way before PBR, at least for your first games.
Indies will never be able to compete head-to-head with AAA in the graphical fidelity department. I’m personally quite happy with the current feature set of Atomic, including on the rendering department. Glow is a fantastic addition which will allow your scenes to ‘pop’ while still being efficient and fully style-agnostic; it works for abstract as well as toon and any other style you can think of.
@JoshEngebretson btw, still waiting for an official word on permission, I could help a bit here