I know UE4 support blender basically but not without problems with rigs and scaling. Does UE4 support Blender 2.8 officially? Unity engine has supported blender with no problems. Has UE4 fixed this yet? I hate having to pay for Maya LT yearly and it sucks as a program overall compared to the new Blender 2.8.
Well actually, I believe I found a work around for some of these issues. What blender grid scale are you using?
The support goes the other way around, Blender needs to make have better export features.
How should they improve? I’m curious.
The workflow between Blender 2.8 and Unreal Engine while not prefect is still workable.
The engine devs opted to follow industry standards while interfacing with formats: obj, fbx, alembic, glTF, and every other 3D tool follows the same. If you want to create a 3D tool you need to follow those standards if you want other tools to import your content, therefore what @darthviper107 wanted to say is that Blender needs to improve that interface, which essentially is generating a more rich FBX content. I do use Blender and when I try to do something simple as I do in 3DS Max and it does not happen painless.
@Waves I am going to check that Blog!
@NilsonLima You can make the argument of who ‘needs’ to do what. But if we look at which side of the divide involves the least amount of work to get a working solution. I think the choice would be on the Unreal Engine side of things rather than Blender.
FBX is a closed format, its official import sdk can not be incorporated into Blender. Everything on that side will always be guesstimates. Better to handle this with a custom Blender aware importer in Unreal Engine. Given how many people this effects and how much easier it would make development for smaller teams. Epic Games stands to gain a lot from providing this kind of support, it would be totally justifiable.
It is known Blender’s Eevvee was made using Unreal Engine as a model to follow and as Unreal Engine source code is available to everyone, it is really easy for Blender devs to look into it, since they are already familiar with the source code when they studied to make Eevvee, so it is a very tiny and specific reverse engineering to learn what UE cares about inside the FBX and how, and apply the knowledge in Blender.
I do agree with you that it is Epic’s best interest, but they are already with tons of things (and bugs) to go after, and if they didn’t provide the engine source code I am sure there would be no excuses. It is also Blender’s best interest to make ppl move from other tools, more than would ever be Epic’s interest.
Hi, please check this (link). Maybe it will be interesting for you.
Unity has a solution to support blender users. What’s Epic’s excuse?
Out of fairness there are other issues to consider no matter how amazing blender is in totality
Unity blender support isn’t perfect as dragging in blend file doesn’t always work as I was hit with that recently, trying to bring in a basic stick character with rig but a fbx worked, shrug.
Another thing for which blender dev’s havent had time(?) to fix is the slow viewport, whereas 3ds max2020 is literaly KING there,I know from experience recently.
That isn’t to say I dont use blender, as I do have projets that work well, but my 2.5 mil tri mesh takes forever to go INTO edit mode, and when there forget doing any edits. It’s a known issue,thats been there for ages ,tho my understanding is they are working on it. No idea wha eta is supposedly nor IF this specific issue that affect many is going to be fixed.
Point: the blender use isn’t as simple as it seems. It may never affect those whose projects are <= 150 or so, but as the complexity increase so do the problems.
Maybe I’m spoiled by having a good computer with 64gb of ram to boot, but I have never found the blender UI to be slow in the past year.
Even faster since I started using the gfx studio drivers.
I’m normally working tons of polygons, and an unwrap of 30k tris or more does take 20 to 30 min. The trick is to work in such a way you never need to unwrap 30k tris or quads actually at once.
Regardless of that. I made my own tools for compatibility, and the FBX format is anything but Close.
you can find all the specs you need to integrate things (like I did for animation curves).
What’s more is that most of the work is pre-done in the exporter for anyone wanting to take the time to modify it.
LODs are essentially already there too. They just work awkwardly, and it’s best to my workflow to script them in as only taken into account when ans empty is starting with LOD_
that’s actually precisely what my curves plugin does.
Is it a nuisance to have to export to FBX and manually import? Sure.
is it a game changer to your workflow?
In fact, I don’t even import materials, often I create the proper material instance before import using the correct variety of automated material, and the import process just assigned the correct unreal material for me based on name alone.
Having Materials come in from blender is bs anyway. Half the textures would be missing as I believe only the diffuse is packed to the FBX. Naturally, that’s also something easy to change, I for one (probably like many blender coders) do not see a point.
All that in mind, I have to admit that I was so disappointed over the lack of tools that I spent my first month coding said tools to achieve a stable production environment.
And I do offer said plugins free of charge despite the obvious cost to me of doing so.
And speaking of free stuff, having Mr. Lima in this thread (yet terribly OT), what’s the status of the community ocean project with .24 ?
Oh, and adding on to the topic at hand, keep in mind that Epic seems dead set against publishing my plugin for blender in a similar fashion as they do with their ArtV2 plugin. I take this to mean they intend to create their own set of tools.
I have just take a look at it yesterday, and found just a little issue which requires a change into BP_Ocean blueprint in order for the ocean material to show up properly. Now @EvoPulseGaming got the Ocean Project ownership, including its discord channel, so not sure yet who will publish the changes for 4.24, but at my discord with the recommendations people already have it up and running (not with raytracing thou, since will require a full review/wait for the end of its development cycle).
UE4 just needs support for proper glTF 2.0 importer / exporter (fully featured) and the problem with data exchange between Blender and UE4 will be solved.
Lucky you, but your experience is not that common, hence the issue . Blenderartist KNOWN issue, has been for a very long time. You must admit, having that much ram while cool and awesome, you don’t represent a large majority, hence why blender dev, faik, last I knew said the viewport ‘fix’ may not come until a few more versions. Blender users admire blender fortons of reasons, but atm , 3ds max 2020 blows it out of the water on viewport performance, but I hope that fact is shortly , if ever, a thing of the past.
Bought new PC, R7 3700x, 64GB RAM, 2070 Super, new M2 drive. Performance is still bad especially using subdivision surface or undo. It’s hard to work on high detailed models.
In 2.79 modeling (with subdv) and undo was faster, but object mode with hundreds of meshes was very problematic,
in 2.81 modeling (with subdv) and undo is really slow, but there is no issue with having hundreds of complex scene and operate in object mode.
Since Blender want to be compared to softwares like Maya or 3Ds Max, I think this issue should be considered as number 1 to fix. I heard already some complaints from my friends that tried 2.81, also asking me what’s wrong
I don’t want to be impolite. Just want to say that from professional perspective this issue keep Blender slightly in the background. If more people will notice that issue, they will bounce of from that software as fast as they wanted to test it.
these issues are known, and should be resolved in blender 2.82
They will not be resolved in blender 2.81 because they need a technical rewrite of some parts of blender, and then they will have to be tested for the right time in alpha and beta mode.
A branch already exists for the UNDO system, it should probably be made more solid and then implemented.
As you will have read on the previous posts, for the openSubdiv accelerate on GPU, first changes have already started "
Sure, but all of that relates to high detail sculpting. How often do you do that anyway? and with the dynatopo tool it’s pretty fast to just sculpt a more detailed mesh and bake the normal map / ao / whatever into the game ready model.
Sure, if you are making movies and really high detail stuff it’s not going to cut it, but I don’t believe it’s a deal breaker considering blender is 100% free.
also, on subdiv. the bigger issue is the time it takes to actually subdivide with the loop tools. if you add 1000 cuts on a plane on x it’s fast. if you then cut y you’ll hang a while. that’s probably some redundancy issue with the way the loop cut works.
More to the point of blender vs anything - if I wanted to I could snag the source and fix it. if the same were the case for Maya or 3ds I’d be out of luck, forced to file a bug, and be told to piss off because no one but me uses it that way.
Not sure where you are getting that information, bc while I’m not sure my issues were sculpting related as I have far better luck and great performance sculpting in AutodeskM MeshMixer. My and logs of blender uses issues are with editing or specifically for me as Meshmixer has always been goto.
Free is always going to matter alot as many can’t afford pricey options, but free, blender ‘atm’ anyway is a joke as relates to working on my 2.5MIL tri mesh. Literally impossible, hence why i use mesmixer for almost everything ,just no choice and that applies to many blender users,and blender devs are aware of it.
Agreed. I hope they are really gonna improve this. Importing a tree with ~1.400.000 vertices makes the programm almost or pretty much unusable in edit mode. The feature set of Blender is nice, but this performance issues is starting to get more and more apparently.
Work on rewriting the OpenGL code is already underway in the 2.8 branch (and a recent Sunday Meeting has the developer hinting at the code being ready for tests sometime soon).
All we can do is wait as of now, but please note that the developers are indeed aware of Blender’s OpenGL being archaic as shown by the project.
Thats all edit mode speak, and while I couldn’t be more overjoyed working with blender for my meshes that are ‘small enough’, my current project that matters the most to me, gives me non usable performance in blender as that thread indicated in 2016, its no better now and many say better in 2.79. I refuse to go backwards, enjoy 2.8X too much so I’ll never find out,but I highly doubt it as last time I used 2.79 its as worse as in 2.8X ,but maybe for others it was slightly better to stick with 2.79 no idea.
Anyway stress in life can be bad enough, so I avoid it where possible which means sadly blender avoidance bc the huge weight of my work is my huge mesh which is a huge component of my current ue4 work
Ok, but let me ask you this.
what are you doing in engine with a 2.5mil tris mesh?
aside from waiting 30 minutes on an import when you forget to triangulate beforehand