Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
You can still use cycles to create your models in blender.
The main difference is cycles uses nodes for shading and such and those are what can't be transferred over.
Or at least that's what I've learned currently based on my own personal experiences with it going between Blender and Unity or UE4.
Usually I prefer to build and make a model in cycles just because it looks a heck of a lot better while working on it but you can strip off the nodes and whatnot if you need to though I never really bother to do that.
From what I've heard PBR is changing that though and it's possible to export it somehow as a pbr-based shader to send elsewhere somehow though I'm not entirely sure how to do that yet or how true that part is eif that's really even the case.
I imagine at some point down the road we'll likely be able to transfer them since Unity has that Shaderforge plugin and UE4 has Blueprints which are pretty much Node-Based scripting. Both are very similar.
modeling is the same in both, difrence is the node/texture setup and way the light works
+1(ish)
AFAIK you can't properly import materials from Blender to Unity you have to do what @Scre says and bake(convert) these into a set of maps(textures) that are suitable for your desired shader in the game engine. It may be harder to generate the needed maps from a Cycles setup than from Blender's internal, so this may be what you have seen/read something about somewhere?
Generally you don't bake the lighting though! If you do bake lighting then you normally do it in the actual game engine and you only do it with static objects.
Baking lighting means you bake shadows etc into the actual texture, if you do this with a character then while it might look perfect in it's initial position it will look very wrong when it moves as the shadows on it and those cast by it will stay where they are!
Games generally use a mix of real time lighting(for moving objects) and baked lighting(for static objects) as baked lighting is less power hungry than real time(though baked lighting will add to the games file size as it creates sets of light map textures).
pbr is becoming the standard, Blender does not support pbr(though you can download some cycles shader node setups that emulate this, they are not perfect though!).
Hopefully they will add something official at some point but at the moment their whole Cycles shader system is based around the spec/gloss workflow(still supported by various shaders in game engines), pbr is metallic/roughness and the data and maps are different(even the ones that look pretty much the same are not, they interact with the other textures in different ways!)
Like @Scre says Cycles and the Blender Internal render engines are just that, renderers! They generate high quality 2D images from your 3D model. They have no bearing whatsoever on your model being usable in a game engine or not.
Requirements for making a model usable for a particular game engine vary depending upon the engine. What they tend to have in common is a high poly to low poly workflow via re-topping (when needed) and normal maps.
Game engines need much simpler models as they have to produce a 2D image 30-60 times a second unlike Cycles(and Blender render) which can easily take half a day to make a single 2D image(depending upon the complexity of the models in your scene). This is probably what you have read, people making high poly models for use in high quality 2D renders which in this state are not usable in a game engine, hence the high to low poly workflow mentioned above!
Blender render is much faster(than Cycles) for viewing your model with decent lighting while working on it(use a simple but effective 3 point lighting setup while working on the model's geometry), only use Cycles if you really need to(a final top quality render of your finished model/scene)!!!
For Garry's mod you will be looking at the Source Engine, google this for more detailed info about accepted 3D model file formats, shader options, model poly count limit, and what rigging methods are compatible(for animation, accepted bone setups etc).
On the whole I would recommend avoiding Cycles for what you are doing. Use Blender for making the 3D model(high and low poly), use the internal render if you want to see it in better lighting, and use Blender for UV unwrapping your low poly model.
If you can afford it look at something like Substance Painter for baking, texturing, painting and map creation. Blender can do this but I never found it to be as smooth or easy as with alternative software.
Unity can use procedural textures created in Substance Painter directly(full integration), this can reduce file sizes considerably and allows easy manipulation/changes of the textures on your model from within Unity. Load times can be longer but the pay-off is worth it! Blender can't do anything like this at the moment!!!
You might want to take a look at Xnormal for normal map creation if you don't want to spend anything.
Hope this helps a bit :)
You can also do the whole thing in Blender: model low poly, UV unwrap, model/sculpt high poly, bake your maps, even paint textures directly on your model, then export the whole low poly asset with your textures. Parts of that chain are not the most efficient yet, but it's 100% doable. Just find some tutorials to follow.