Yep same problem and I can't find anything on the internet! I have the same issue when using USD!

putting the code inside a plugin can do the trick

Thank you! I think it's mainly a function of minority piled on top of minority. I'm just guessing, but I think the majority of people who use Godot want to use GDScript for it's simplicity. Of the C# people, most don't care about compiling it from source, less so on Linux. There might also be some residual perception that .NET doesn't mix well with Linux, even if that hasn't been true for quite some time. But mainly, I think it's a fundamental aspect of an open-source engine that isn't documented well. You can find how to compile this thing left and right, but it's almost always the vanilla version without .NET.

I would need to know how it happened first, but smoothed and different poly count are two different things. Are both of those definitely happening? Did you, perhaps, import multiple objects and compare the poly count of a single object in Unreal vs the entire scene in Blender? I have heard of the opposite problem--in which you have fewer polys in Blender because of the LOD setting in Unreal (which you would want to disable), but never higher poly count.

@@Holonet01 no, the topology is same. But it’s like when exporting, subdivision surface modifier has been applied. In unreal the poly counts are less and they are low poly but when I imported those fbx into Maya they have much larger poly counts and in blender also. They look like when you have applied subdivision surface modifier . Sorry my English, I can also show you the screenshot if you are not able to understand this.

I think the lights would be separate objects in Unlreal, wouldn't they? I'm not sure a light would be considered a "model" which you would import or export via gltf. In any case, lighting is never going to be identical when you have different render engines, so it would probably be better to just plop the lights you want in the scene after import if that's what you're after. Or, if you're planning to export them to a different game engine, to create the lights in said game engine.

I don't know, that's a whole different beast. I'm not sure how inherently compatible particle systems are between Unreal, Blender and/or whatever game engine one might export to. Personally, I wouldn't put the effort in to do that, I could be wrong, but I don't think particle systems are nearly as standardized a format as 3D models. If you need objects as particles, I'd just focus on the object an create the particle system wherever the final destination is.

Thank you!

Right, Blender will map to them if they are not packed into the binary. Also, you can then modify them if desired.

You got it 👍

You're welcome!

Yeah, I would think so, the most obvious tool I can think of is probably Automatic1111, but there are others. They document their API here: github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/API It would probably look a little different depending on the protocol they use, but certainly possible.

Yup, take a look at the ReadMe on the repository. I give a little overview of that there. I added a little code to spit out all the files which are basically in the .gitignore. You'll see that MissingFiles.txt file (generated each time the project runs), which lists all the files in those folders w/ those assets. I also have an explanation of what I'm doing in general as far as scale. If you replace those files, the code should run.

@@Holonet01 great thanks

Yup, audio has been a complaint on this video and I realize why now. I did actually try to tone down the music in the middle, but apparently not enough. Listening again, that's not what I uploaded, it clearly became victim of KZbin's automatic volume compression, making it considerably worse :(

It should be, as long as their gltf exporter does the job, as gltf supports animations. It might take some tweaking of settings, it might not. Best suggestion I have is try it :)

Never used metahuman, but it should be fine if it ends up as a standard mesh, armature, etc... My gut feeling is it should work, but I wouldn't be surprised if there were some pain points. One thing I'd be trying to avoid is dealing with material fidelity, though. With skin, it's a lot harder than most materials to be satisfied with the result on that front, in my opinion anyhoo. Depends on your end goal too...like if your end game is in Blender, or to do stuff there, then back to Unreal (then hopefully you could reassign materials, but there are other headaches coming back in, etc...).

@@Holonet01 im still a noob so when I tried I just imported blob lol but it did download all the materials which is weird

Thanks! I wish I could always avoid weird workarounds :-P

My pleasure!

No probs =D

Depends, but first thing is, make sure you are using Unreal 5, and I think it was an external plugin for a spell prior to being there by default. Here's the actual plugin page: www.unrealengine.com/marketplace/en-US/product/gltf-exporter?sessionInvalidated=true You can add it from there if nothing else. It looks like it says there, that it's also for 5.0, so it might be that it's only in by default as of 5.1.

Well, allowing for the self-evident problem that I can't tell you what you did wrong without seeing your script :-P, the two things I would check first are if you forgot to put the [GlobalClass] attribute above the class, or if you didn't build the project. That's really all there would be to getting it to simply show up, even if you mis-copied anything else.

i got it working just fine now. sorry about that

Well, this video has nothing in violation of that. Nothing says you can't modify an asset in Blender and then reimport it into Unreal. Having said that, by all means, export to other game engines =D. What you're referring to is only true for assets actually "made" by Epic, stuff like the Megascans and I think maybe Paragon stuff or something. You can see the terms for the Marketplace here: www.unrealengine.com/en-US/marketplace-guidelines I'll save ya the trouble of going through it though, here's the important bit: ---------------------------------------------------------------------------------------------------------- 4.2.1 Usage Rights 4.2.1.a Purchasing a Marketplace product grants to the purchaser a non-exclusive, worldwide, and perpetual license to download, use, copy, post, modify, promote, license, sell, publicly perform, publicly display, digitally perform, distribute, or transmit the content for personal, promotional, and/or commercial purposes under the Epic Content License Agreement. Distribution of products via the Marketplace is not a sale of the content but the granting of digital rights to the customer. 4.2.1.b Sublicensing Marketplace assets in Source Code format is prohibited. Sublicensing Marketplace assets in object code format, or any Content, is also prohibited except to grant end users the ability to use, or to permit sellers and distributors to market and Distribute, a Product Distributed as permitted in Section 3(a) of the Epic Content License Agreement. 4.2.1.c All content hosted by Epic Games is exclusively downloadable through the Epic Games Launcher. Once downloaded, most content can be exported to obtain the source files and/or migrated to other existing Unreal Engine projects. ---------------------------------------------------------------------------------------------------------- Now, that last bit might sound like it's limited to Unreal Engine projects, but it's not a restriction. The "Epic Content License Agreement" in there is actually a link on the site: www.unrealengine.com/en-US/eula/content Within that page, here's the meat: 2. How You Can Use the Licensed Content We grant you a non-exclusive, non-transferable, non-sublicensable license to privately use, reproduce, display, perform, and modify the Licensed Content in accordance with the terms of this Agreement (the “License”). This means that as long as you are not violating this Agreement, such as by using the Licensed Content in violation of any applicable law or regulation or for any unlawful purpose, you can privately use the Licensed Content however you want. If you want to share the Licensed Content or anything you make with it, Sections 3 and 4 addresses when and how you can do that. So, they literally tell you that you can basically do anything that you want as long as you're not violating that agreement. What you might have been referring to is this part: 5. Other Restrictions on Your Use of Licensed Content a. UE-Only Content “UE-Only Content” means Licensed Content that is designated as only permitted for use in conjunction with Unreal Engine and Unreal Engine-based products as designated by Epic, such as Twinmotion. So again, that's only that specific content that you can only use in Unreal Engine. Regarding the artists' permission, in other parts of that mess, you'll find that if you submit something to the marketplace, you grant Epic all that stuff. Wouldn't really work too well otherwise, I imagine. No one would want to buy stuff from a store that they actually have to read a different EULA for every sword, thatch house and cyborg LOL.

Just scene. I imagine game-wide would probably be problematic, as the editor would need to check to be sure you didn't duplicate a name, and when the game is run, the node with the name would have to be loaded in the scene tree or it'd throw an error, and to handle that, I think they'd need to force it to autoload or something, etc... If you're trying to access something like that, there are a few ways that make sense depending on the purpose, if there are multiple, etc... You could get an instance of the scene, and then get a property/singleton/whichever, or you'll see me use static variables a lot, and set their values in the Ready() method. This works fine if you only have 1 of the thing you're after.

You should be able to, yeah. I don't use Unreal to animate, so I can't say I've done it, but gltf certainly supports animations. Ultimately, as long as Unreal's exporter works well 😋

Thanks much!

Great to have you here, and thank you for that original script!

Yeah Chrono Trigger might give an impression of less complexity because there's just less "stuff," spells, etc... but it definitely has its own stuff. It would be different there because the battle area isn't separate, it just takes place wherever they are. Some things would be easier, others not. Actually, I think navmeshes would be tricky in that case, because you don't really have a "fixed" place where you'd want the characters. Not knowing how they did it originally, it's clear that there's some logic about enemy formations, where they will go to at battle start, spacing between the characters, etc... At the same time, as I think about it, there are probably specific battle areas wherever there are enemies, and maybe if you run into one at such-and-such a location, everyone bolts to their location(s) in the nearest "battle area." In that case, there could be navmeshes there hidden except while in battle. You might not even need that for the original behavior, though. I feel like they would go to their spots, then a lot of what happened could be based on the location of the character and the enemy they're interacting with. The fun challenge there would be the double & triple techs =D.

Thank you! And quite a tasteful avatar you've got there 😁

@@Holonet01 Thank you! Might you have a discord?

I don't have an actual server, and it might be a headache to out a Discord ID in the comments. Not sure, BUT, a friend of mine (www.youtube.com/@RandyFluharty - he's doing game dev too but his content is more streaming)has a server, and he's cool with me posting a link here, and I can be found there as well. He's got a game development channel within there: discord.gg/zZ3hJwZQ

Yep, Chevifier pointed out what basically amounts to that and I pinned his comment ^^^. Personally, I still like to set it up this way from a strictly organizational standpoint, but you're right that it is not necessary. The sub viewport is also not needed, but you can play with it and do some other stuff if you like, say, having a UI in a region of the screen, etc... I haven't tried the control node without a canvas layer at all, but you might want the canvas layer there, at least, even if it's not positional. If you end up making a more complicated UI, you might want to put stuff on top of each other, and need to specify the rendering order/layer.

@@dondahighhh12 Thanks! You're welcome 👍

no

Under most circumstances, I don't think it would, unless it's enormous and you want to read & write from/to it rapidly, then possibly. But it depends how you're using it. I'd be curious why you would prefer that, though? The one thing that's unfortunate about that is the player can just open your game data in a text editor and change everything, and likely break stuff. You could try locking it down somehow, but I think that'd be more work than using a database of sorts.

@@Holonet01 Thank you for your reply, your videos have helped me a lot!

My guess is you're not running the command from the repository folder 🤔 To clarify, you do not need mono. It is simply referred thus in Godot's folders, etc... because they haven't bothered renaming all that, but it uses .NET now.

Yes, thank you. I suppose I do need to credit it for existing as FOSS in the first place 😋