CryEngine is Finally Back ! :D
polycounter lvl 12
HOOOo--LLLly S..T !!!
They actually delivered
....3.8.1 is here....
http://docs.cryengine.com/display/SDKDOC1/EaaS+3.8.1
- GameZero Template: Just like UE4's blank template. There no mummbo jumbo code. Only bare essentials. Go, learn make your own game.
- VR is out ! Go use and try it !
- A new experimental real time Global Illumunation system for much higher quality real time lighting (CORRECTION ! ) (Experimental currently ! )
- Linux is on !
- OpenGL baby.
- New fog system: Voxel Base can be illumunated by normal-colored lights and even can simulate vortexes !
- Parallax Occlusion Map is fixed and improved ! Fşnally !
- Road tool improved !
- **** ton of improvements and fixes !
I know %90 of people here really dislikes the engine and I respect them, but I just want to state that I am a happy panda that now I have two very capable engine under my hand.
So just leaving this here.
They actually delivered
....3.8.1 is here....
http://docs.cryengine.com/display/SDKDOC1/EaaS+3.8.1
- GameZero Template: Just like UE4's blank template. There no mummbo jumbo code. Only bare essentials. Go, learn make your own game.
- VR is out ! Go use and try it !
- A new experimental real time Global Illumunation system for much higher quality real time lighting (CORRECTION ! ) (Experimental currently ! )
- Linux is on !
- OpenGL baby.
- New fog system: Voxel Base can be illumunated by normal-colored lights and even can simulate vortexes !
- Parallax Occlusion Map is fixed and improved ! Fşnally !
- Road tool improved !
- **** ton of improvements and fixes !
I know %90 of people here really dislikes the engine and I respect them, but I just want to state that I am a happy panda that now I have two very capable engine under my hand.
So just leaving this here.
Replies
I meant "spirutally"
Just could never get anything into it from modo without mental workarounds and constrictions.
is there anything new regarding importing FBX (besides 3ds) and textures ?
But they promised FBX support for everything (characters, vehicles etc), and so far they delivered superbly so... next update I suppose ?
I aksed for this feature many years ago and crytek people told me: never! :poly142:
Linux only or Win DX10 GPU as well?
@ Blond. Here you go. (Thanks to Collin Bishop ! )
[ame]
The full list:
https://www.youtube.com/user/Free3Dee/playlists
It's roughly the same UE4. The only difference is that you use gloss maps instead of roughness (white = glossy, black = non-glossy) and colored specular instead of metalness. Personally I find it slightly more intuitive, but that may be because I've learned this method first.
EDIT:
Oh my, that new GI system
I must try this with skin and eye shaders at once !
thanks
they added Fbx support through Maya + plugins or can you send your meshes directly in CE ?
Im asking because i find CE to be tedious to work with large number of objects.
https://youtu.be/6GSLCik6F_w?t=7m26s
http://www.crytek.com/news/crytek-adds-support-for-three-new-platforms-in-latest-cryengine-update
Right now static meshes can be used. And possibly next update or the other one will get other types (characters, vehicles etc)
There was this Polybump application they provided sooo long ago. Maybe that was what you are asking ? If that is you don't have to trust it just export them from PS.
Basically, there's no one way to calculate normal maps; each program does it slightly differently. Lots of programs (like Marmoset, UE4, etc) are synced to the same tangent-basis (the way that the normals are calculated and read) as xnormal. That tangent basis is called MikkTspace, and it's slowly emerging as the standard.
Having a renderer that reads using the same method as your baking program writes, is called having a synced workflow; and it eliminates so many of the common issues people have with normal maps.
But CryEngine uses CryTspace (now the official unofficial name), as far as we know; so it isn't synced with any baking program we have access to, and there are bound to be shading errors (though they may only be minor, I'm not sure.)
The tangent basis is formed by three vectors which are perpendicular or close to perpendicular. There's the normal vector, which points straight away from the surface and which Cryengine supports importing. Then there are the tangent and bitangent (aka binormal) vectors which are perpendicular to the normal vector and to each other and generally point along the surface of the mesh. For every vertex with UVs on your model, the tangent vector tells the renderer which direction +V in UV space corresponds to in 3D space, and the bitangent vector tells the renderer which direction +U in UV space corresponds to in 3D space. The thing is that these vectors can basically point any way you want them to as long as they're perpendicular or almost perpendicular to the normal vector and to each other, so you can have them facing pretty much any way you want as long as it's consistently calculated and it will be a valid tangent basis. To have a synced workflow is to either have both the baker and the renderer calculate the tangent vectors the same way, or to have the baker tell the renderer what tangents it used. As long as the renderer and the baker are on the same page, the normal map should come out looking right.
When the baker and the renderer are not synced, you can keep shading errors to a minimum by capturing most of the low-frequency details in the normals of your low-poly model. You'll often need to edit some normals or add some extra geometry that you otherwise wouldn't need in order to get this working.
CryTSpace (which is just a term I coined now btw, I don't know if it actually has a name) is therefore not worse than other tangent spaces because the tangent and bitangent vectors it puts out are wrong in some way. The reason it's worse than other tangent spaces is because there's no way you could possibly be synced to it. There's no documentation or source code available about how it works except for an old binary xNormal plugin that doesn't work and it doesn't match the tangent space of any other application out there. So there's no way for any baker to calculate CryTSpace on its own. And Cryengine doesn't import tangent and bitangent vectors from your 3D program, so you can't get a synced workflow by Maya or Max telling Cryengine what tangent and bitangent vectors to use. That's why I like xNormal+UE4 better as a person who obsesses unhealthily about normal map baking. UE4 can import tangents from Maya, Max, or Blender if you use the FBX format, and it can calculate tangents in a standardized fashion (or almost standardized for skeletal meshes.) Even Unity, which tends to lag the other two by a few years in terms of realistic rendering features, has a tangent space plugin available, and it can also import tangents from DCC programs. So for portfolio pieces I would even prefer Unity to Cryengine for that feature alone, despite its slightly lesser out-of-the-box rendering features.
On a side note, knowing that the industry is slowly progressing towards an accepted standard for TS normals is such a relief. It's kind of crazy to think that it took about 10 years to get there, with a lot of misinformation, misunderstandings and innaccurate pipelines along the way ...
Here:
http://www.cryengine.com/community/viewtopic.php?f=315&t=131467
Hope that helps.
edit: TAN, I took a look at your link but it seems that while it may be synced the engine still messes something.
It is fine, even for eye candy mate
Also yes. Looks like some people are having problems with seams. Interesting. I picked up a habit of at least giving 2-3 pixels border space for map baking 1 year or so ago. Maybe that worked for me ?
But I'll keep this in mind if I can gather any more data I'll share it mate.
This is hardly noticeable stuff on organic models, but a fondamental thing to get right for hard surface objects and/or cinematic quality assets. This is really the core of the whole "synced or not synced" discussion
As a matter of fact this kind of stuff should typically not be judged by merely looking at the results with the naked eye but really should be coming from correct math backed up by the tech team. Because while things might look "good enough" in some cases and at first glance, one can end up losing a significant amount of man-hours in production later down the line because seams start to appear on more demanding models. Been there, done that, and that's a pain.
Now it is still very possible that the current iteration of the engine and its model importer are indeed synced with Mikk - but considering that this area of Cryengine has always been finnicky in the past (to say the least !) I think that a little bit of healthy skepticisim is fair
Also the prominent staff behind the latest build will be on twitch stream answering questions. Details:
http://www.cryengine.com/community/viewtopic.php?f=328&t=131473
Of course this is uncompressed so there aren't any compression artifacts, but you can see that it looks like my highpoly model.
Here is my UV map.
Now, here's the first model in Cryengine. This model is exported using the Cryengine Maya tools.
There are compression artifacts of course which is no big deal (every engine has those) but there's also those weird dents in the surface. This is a characteristic error that you would see when the tangent space isn't synced correctly. Also, the bent normals render target should be a solid grey if the surface is really flat. (Unfortunately the scene normals render target seems to be broken: it only shows the full beauty render of the scene.) The final piece of geometry was exported from Maya to an FBX file and imported into Cryengine using its FBX import.
There are still dents, but these dents are different. So not only is Cryengine not synced with Mikktspace, it also calculates the tangents differently when you import the mesh in different ways, which is literally awful.
If you would like to test my data aginst the licensee version of CE and see if you get any different results you can take a look at my data and see if you can get any different results without changing the mesh normals or the UV map.
Until then, the verdict is that Cryengine doesn't support MikkTSpace.
Now it's time to find out if Steam refunds work on subscription payments.
There might be another factor to consider, just in case : to my knowledge and ever since Maya 2013, Maya offers a choice between four different kinds of vertex weighting, with "Unweighted" being the legacy, pre-2013 option. Unfortunately this legacy option is not set as default, which can throw a wrench in many established asset pipelines (for that too : been, there done that, painful stuff). More on that here :
http://download.autodesk.com/global/docs/maya2014/en_us/index.html?url=files/GUID-232E99F8-96B4-4870-8BA0-4887C1C8F0F2.htm,topicNumber=d30e189713
Therefore while I would expect FBX to fully export such data (and FBX importers to fully read it) it might be interesting to check what happens in CE with a cube set to "Unweighted" (either as a per-object setting, or globally) before export and a new bake done with that. With Crytek being a Max-oriented studio and Max using unweighted normals as default, I wouldn't be too surprised to hear that CE might expect this kind of "raw" normals on import - and bakes created accordingly.
It's a shot in the dark but maybe worth investigating ! Now of course that wouldn't mean that CE "supports Mikk" as the whole point of a synced solution is to not have to worry about exceptions of any kind, but at least that could be a possible workaround.
I wouldn't be surprised if that's the case. I replicated Jed's test in Max:
My one is on the left. As you can see, it worked perfectly!
I used the same highpoly, but made a new lowpoly, using the same UV layout and one unified smoothing group. I then rebaked it in xnormal with all default settings, except for the y channel being inverted.
I'm not sure if there's a toggle for it in Maya, but in Max, for the custom mesh normals to be properly exported you have to tick the "Custom Normals" box on export.
Does that make a diference?
Something's still a bit fucky with the face on the left of the cube. It's certainly better than my efforts but still not as perfect as it would be in Marmoset, Blender, or UE4. Besides, if Cryengine used true MikkTSpace why would it calculate different tangents for my two different cgfs? MikkTSpace is order-independent so for the same geometry with the same normals it should output the same tangents.
As far as details of how I put the vertex normals together in Maya, I used Average Normals, then Lock Normals, then Triangulate, with the normal calculation method set to Angle and Area Weighted. But the normals should be the same pre-triangulation with any of the methods for this particular geometry.
I upgraded to the latest xNormal for this test, but it shouldn't make a difference if you're using one that's a few versions back.
Mystichobo: Have you got "Calculate binormal in the pixel shader" checked in the xNormal MikkTSpace plugin settings? I baked with it checked because that's synced with Blender, Toolbag and UE4 (but not with the xNormal 3d viewer.) Also, could you perhaps upload your source files so we can all take a look for ourselves? And finally if you could show us the bent normals or scene normals render targets with r_showrendertarget $SceneNormalsMap if it works or r_showrendertarget $SceneNormalsBent it would be helpful.
Also does anyone know how to get Cryengine to show tangents in the viewport?
While it seems that Xnormal generates the same output for "Object Space Normals" and "Bent Normals" maps, my understanding is that these are supposed to be two very different things (OS Normals being what they are, whereas a "bent" normals bake is just a clever way to inject pseudo AO shading "light bending" into a OS map).
This is hardly relevant to the problem at hand, but I thought I'd bring it up in case it affects the debug render passes you are talking about.
About the normals : you are correct, I somehow assumed that you were using abeveled cube - but indeed for a 8-vertex cube it should all be the same regardless of the Maya weighting setting.
Also for the FBX export settings, I have Smoothing Groups checked, Smooth Mesh checked, and Triangulate checked, and all other mesh setting unchecked, in line with the UE4 docs.
I'd say that it's likely something fucky going on during the export/how the cgf is compiled. I think the left face may just be the oblique angle/screen space reflections messing up, but I'm not 100% sure.
Nope, I rebaked and tried that and got a very similar result as yours.
Sure, not sure how helpful they will be. The first rendertarget shows nothing more than the standard rendered image, though that may be something wacky in our build. The bentnormals shows the following:
r_ShowTangents 1
I'll see if I can ask Crytek about the issue, but I'm not 100% sure I'll be able to post the answer here if I get a response.
In Photoshop I painted over the render target with 127, 127, 127 grey, then set the layer blending mode to Difference. This should nicely highlight any areas of the cube that aren't flat. Some of the other cube faces are not correct.
This one doesn't look too bad on the bent normals target but if you run a color picker over the top right and bottom right corners you can see that there are problems there.
So, the conclusion that I draw from this is that Cryengine uses something that's close to MikkTSpace with an inverted bitangent vector, but fails on the UV seams causing some pretty serious artifacts. This is usually caused by trying to implement the tangent basis yourself because of company policy on third party code, thinking you're done because it works well on areas that are off of UV seams, and publishing your program. Fortunately, there's an easy fix if you're a Crytek rendering engineer. Throw out your old tangent basis code, go to this page and follow the directions, telling the library that you don't want to calculate the binormal in the pixel shader to be consistent with your previous implementation. The open-source implementation is free for commercial use, not GPLd, so you should use it to make sure that your tangent basis is 100% correct. It's kind of like the STB libraries in that it's super easy to integrate. Also, you should document somewhere that the box needs to be unchecked in the xNormal MikkTSpace settings so that people who are coming to Cryengine from other engines that require it to be checked (i.e. every other mikk renderer out there that's not xNormal) know that they need to change the setting back.
Conclusion: still not Mikk, but definitely easier to bake to than I originally thought.