[Crash]Placing Static Meshes quickly

  • I decided to edit the title because it seems we’ve discovered a new crash related to the Random Foliage Blueprint…

Hey all,
So I’m wondering if there’s a faster way to place tree models in my level. Currently I’m placing a few by hand and then selecting those few and cloning them. The problem is that this is still relatively slow and the placement of the trees is less varied, so I have to manually re-size and rotate them more after.

Basically I’m looking for something that’s the equivalent of the foliage painter but that will support collisions.

Any ideas?

Hi Peter and Mehmet,

I tested this in Rocket, and I was able to get the crash (just like for you, the Callstack was empty, so it is absolutely useless to us).

I have also tested this in our current internal build, and I could not get the crash to occur. This leads me to believe that whatever did cause the crash has been fixed since the release of Beta 6.

Thank you for the information. I will continue to watch for this one.

Cheers

Good to hear. Thanks for looking into it Stephen!

Seconded. Looking forward to the next update as this is an awesome time saver that I’m really looking forward to being able to use.

Have you checked the samples that have flowers in them? Setting up a blueprint like those with your trees can give you what you need, and with collision too.

Blueprint Examples and Content Examples demos have such blueprint setups.

I’ll definitely look into it. I’m downloading content examples now and I’ll take a look at the blueprint example asap as I just downloaded it yesterday.

Thanks

So I tried using the flowers blueprint from the Blueprint example; It will place without any problem, and I see my trees laid out, but the editor crashes if I try to move the blueprint in the 3D View. Maybe something to do with the line traces to figure out where to place the meshes on the terrain?
Here’s a screenshot of my defaults:


Any suggestions for what I should change? There’s only 2 meshes referenced in my example instead of 5 from the flowers.

I haven’t used this blueprint but doesn’t it say “Number of meshes = 15” ? Maybe you need to set it to 2 ? Again, its just by looking at the above screenshot.

No, this is how many copies of these two meshes it will place. The idea is that I’m making a forest scene and rather than having to manually place, rotate and re-size 15 copies of these two meshes by hand, its going to do it automatically in one step. It could however be something as simple as I’ve only given it 2 meshes and I’m telling it to place 15 of them in the scene but 15 is not evenly divisible by 2 so a number like 14 or 16 might be better?

But I doubt it because as I mentioned, it IS placing the meshes in the world. The crash comes when I try to move them. I’m guessing this is because it has to do a lot of calculations as to where to properly put the meshes when I move them in the world so that its placing them at the correct height on the landscape. IE large differences in height value means more calculation which causes the crash. Cause if I place the Blueprint on relatively flat ground, its fine, but if I try to place them on very uneven terrain, it crashes even when placing.

It may be related to this issue:

https://rocket.unrealengine.com/questions/12806/crash-crash-when-placing-blueprint.html

I can’t check it myself right now, since my Blueprint Examples demo seems to be corrupted and it doesn’t even open so i’ll have to download it again.

I’d love to know, but sadly the crash report I’m getting has no details in it.
Every time it happens, I get the following:

Have you tried playing around with that flower BP without any modification and see if it crashes as well?
Btw, there should be a text file for the log in your project folder>Saved>Logs. It may help Epic people see what the problem is if you upload it here.

No, I haven’t tested it with the unmodified flowers in my scene, however it DID work while moving around inside of the Blueprint demo and I’d imagine its not going to crash in my level either, due to the lower radius. I really think its the radius that’s causing the crash because its requiring too much info from the line trace to figure out where to place the meshes on the ground. Haven’t had a chance to play with it yet, but my guess is if I lower the radius, it’ll stop the crashing. Only problem there means I might as well go back to planting trees by hand if I can’t do more than 2 or 3 at a time.

Interestingly enough the crash seems to happen with PhysX.

[2014.01.24-07.42.48:566][377]LogWindows: === Critical error: ===


[2014.01.24-07.42.48:566][377]LogWindows: Fatal error!


[2014.01.24-07.42.48:630][377]LogExit: Executing StaticShutdownAfterError
[2014.01.24-07.42.48:637][377]LogPhysics:Warning: PHYSX:  (1110) 8 : PxScene::lockWrite() detected after a PxScene::lockRead(), lock upgrading is not supported, behaviour will be undefined.
[2014.01.24-07.42.48:637][377]LogPhysics:Warning: PHYSX: ..\..\PhysX\src\NpScene.cpp (2861) 8 : PxScene::unlockWrite() called without matching call to PxScene::lockWrite(), behaviour will be undefined.
[2014.01.24-07.42.48:637][377]LogPhysics:Warning: PHYSX:  (1110) 8 : PxScene::lockWrite() detected after a PxScene::lockRead(), lock upgrading is not supported, behaviour will be undefined.
[2014.01.24-07.42.48:637][377]LogPhysics:Warning: PHYSX: ..\..\PhysX\src\NpScene.cpp (2861) 8 : PxScene::unlockWrite() called without matching call to PxScene::lockWrite(), behaviour will be undefined.
[2014.01.24-07.42.48:639][377]LogPhysics:Warning: PHYSX: ..\..\PhysX\src\NpScene.cpp (2861) 8 : PxScene::unlockWrite() called without matching call to PxScene::lockWrite(), behaviour will be undefined.
[2014.01.24-07.42.48:640][377]LogWindows: FPlatformMisc::RequestExit(1)
[2014.01.24-07.42.48:640][377]Log file closed, 01/23/14 23:42:48

I’ve attached the entire log file as well…link text

So, i managed to try it with the random foliage BP, and looks like it crashes Rocket whenever the blueprint intersects with landscape. Tried it both on a clean landscape and after adding a couple of hills and got the same result, no matter what the radius and number of meshes are. It works fine with static meshes however so i guess this is a landscape related bug. :\

Interesting discoveries Mehmet… I tried to test different scenarios using the RandomFoliage BP in the Blueprint Example project and now it crashes no matter what I place the BP on top of. Static Meshes, Landscape, whatever. If I simply create a new level and then place it directly onto the ground mesh that’s there by default, it works ok. However, if I throw in a pyramid, scale it up to 4x and then lower the Z to 0.5 to create a hill and then move the BP onto the pyramid, as soon as I let go of the Left Mouse after moving, the editor crashes.

I decided to record a video of this happening…

It seems that the Blueprint works perfectly inside the Blueprint example map, but as soon as you try to use it outside that scene, the game crashes instantly.
Is the blueprint somehow tied to the level itself maybe and thus won’t work in other levels?

I had placed it on the default ground box of an empty project, then also duplicated it, rotated a little and moved the BP around and didn’t get a crash. I haven’t tried with a single shape like a pyramid. But after your post i managed to crash it with a static mesh too after several attempts(i moved the BP up and down, left and right rapidly so it makes sense i think). Eventually it doesn’t crash for me as often as it does with you, unless i place the BP on a landscape.

Hi Peter,

I must request that you please remove the video from YouTube. I appreciate that it is unlisted, but we require you to not upload any media that shows off the Editor UI in whole or in part. You are welcome to upload your video to the Rocket FTP that Epic has made available to you.

Thank you.

p.s. I am investigating this crash.

Oh, apologies. Its been removed. I thought I remember reading an e-mail that said it was ok to show off our game now… I’m guessing that meant not including showing the editor itself?
And thank you for looking into the issue.