moving actors that have a static mesh, and other questions

[Graham.]

I have a few questions.

My game is going to be very "procedurally generated". Levels, models, lighting setups, and so on, are created by code. This brings up questions about lighting, mostly.

Right now I am trying to move a block around an empty space with UnrealScript. I use an Actor class, and try to set the StaticMesh member variable to a mesh I made that is just a cube. This cube does not move when I run the game (but it appears and collides with the player). I don't know why. If however I use a different mesh, one that came in an included library - a barrel - the owning Actor moves just fine, carrying the player around the level.

I checked the properties of both meshes, looking for differences. My cube mesh is a converted brush. What am I doing wrong here? Is a regular actor the best class to be using?

There are many different types of objects that I would like to create. Some are placed by code, once - and have to be placed by code. Some will move once or twice over the course of a "level." And many more will move a varying number of times.

What are some of the things I should think about? Dynamic lighting is expensive. What is the best strategy for using lightmaps on objects that are being placed by code? I can always script UnrealEd. Is there an API for this (for UDK)? There are other ways....

So two questions:
1. simple: why isn't my (cube) actor moving?
2. harder: what should my approach be with dealing with the lighting of generated geometry?

Note, much of my level can be generated at compile time if needed, or just before or whatever. So writing code that produces code, or scripts UnrealEd, are potentially reasonable options.

Thank you for any assistance.

[Spoof]

There are quite a lot of threads about dynamic level management, mostly with keywords like procedural and Minecraft. There's even one in my sig.

There are limits and solutions, but modding UnrealEd is not one of them. That level of modification is only achieved with native code and a full UE3 license. In UDK dynamic level geometry will pretty much require leveraging the dynamic lighting path. One option to avoid this is to choose an alternative art style for the game, such as toon shading or minimalist geometry.

Another solution is to have a strict modular construction and bake your lightmaps outside UDK for each prefabricated element. This will prevent you rotating them, but they should slot together without too many artefacts.

[Graham.]

Ugh. Not what I wanted to hear.

One solution is to generate the world geometry with a script that literally controls UnrealEd. That's what I mean. Like a series of Hotkeys, scripted, click on visual controls and place things. I'm going to research this obviously. I read the post in that 'Minecraft' thread in your sig.

Cursory Googling suggests I can unpack UPKs and do things that way. I'll try pre-baked lighting as well.

I'll probably be able to figure this out eventually, but since I'm here, why do I have to be "strictly modular" to pre-bake? I don't mind generating everything, though would I not be able to mix and match where the lightmap is coming from? (Is that a newb question?)

Another solution is to script 3DS. If, for example, my world is all cubes - and it's not, but whatever - I can generate a single giant mesh in 3DS, then create corresponding collision cubes dynamically to fit over top all of the pieces (in unreal).

I'll post progress.

--

edit: I should say I already plan on using "minimalist" geometry. A primary goal of my design is to stretch construction primitives to the max.

edit2: I should say I think the pre-bake solution sounds the best. I do multiple bakes at multiple rotations.

I have learned that a single giant mesh is a bad idea, because culling is no longer automatic. So I have to split things into chunks.

[Spoof]

I would experiment with the toolset as much as possible, familiarising yourself with the static workflow, getting to know how things work and understanding 'the unreal way' as its often referred to. This will help highlight the reasons why UDK (as opposed to UE3) has limitations for dynamic content generation.

Its not impossible to have dynamic levels, but you have to accept that you can't have your cake and eat it

[Graham.]

Well, I'm new to Unreal, but not to games. There are very strong reasons for generating my content. I'd rather shoot myself than go static (that's not even an exaggeration).

However, what you say is correct. I still need to learn. Unfortunately I know that I want all content generated straight from the beginning so I still have to deal with this stuff, like right away.

Who said anything about having a cake? I wish to only eat. ... Whatever way I need to bend to make this work I'm fine with.

What should I read to learn about dynamic lights interacting with baked lights? This weekend I'll try out external baking mixed with a single dynamic light moving around. Does this work at all? Or is it just ugly? I'll learn as I go, but if you or anyone wants to talk about it I'll listen to that too, obviously.

Some more thoughts I have:
. what complications will I encounter in using pre-baked assets?
. can I bake a scene in UnrealEd, then import it into a different one (you know, like a "module")?

Thank you for your help Spoof. I'll go through more stuff in your sig b/c there's good stuff there, and of course the forums themselves.


--

edit: As you say I will experiment with the "static workflow" as well, in case that wasn't clear.

edit2: Is this a solution to my first problem: DynamicSMActor_Spawnable? Is that what I should use for moving meshes (that are 'static' i.e. not animated)? Maybe my understanding of "static" is is wrong. My next attempt, after this one, would be to check some example code.

[Spoof]

Well, personally I would start without pre-baking anything. Just use the basic map template and start spawning some meshes in realtime through script. KActorSpawnable is a good candidate as they'll bounce around and demonstrate the light and shadow interaction. Set the WorldInfo's KillZ property a lot lower than the default 0 to avoid destroying actors.

DynamicSMActor_Spawnable is useful for static geometry or moving geometry. Regarding terminology, a static mesh is simply a mesh with a fixed vertex array and no bone animation. It can be static (stationary) when used as a StaticMeshActor, or dynamic (moving) as in DynamicSMActor. KActor is based off DynamicSMActor too.

The system is flexible enough to build the same functionality from scratch, deriving from the Actor class. The key differences are the properties bStatic and bMovable, which the engine uses to flag fully static elements and optimise the rendering pipeline. It's possible for fully static actors to become dynamic... if you follow the API thoroughly you'll find how that's done. UnCodeX is a good way to browse.

PrimitiveComponent is an important class and the real workhorse of the system. Actors are just empty shells to host components, and PrimitiveComponent forms the foundation of mesh and collision.

[Spoof]

Just to add, this is the UDN hub for lighting. There are many more pages, some under different sections like performance and profiling that give more info. Lots to browse there.

[Graham.]

Thank you. That's a fair bit to get started. I'll post back when I've done some dev work next.

--

edit:

So I'll be trying out static first, and see how far I can go maintaining 60fps. But I'll likely spill over into bake early on.

[Graham.]

So I haven't had the chance to hit some code until today. That's how it's like with work. Anyway I'm trying to move these blocks around - just simple cubes with collision models that are the cubes themselves. I just have instances of the cube being spawned in code.

Okay so my problem is is that they don't move. I subclass DynamicSMActor_Spawnable. When I walk off a block with my character it falls down gracefully, endlessly. But they aren't moving around according to my code. If I use a different static mesh they move around fine. The static mesh I want to use is just a cube converted from a brush. The static mesh that does work (that can move) is a barrel from a packaged library.

What is going on? What is wrong with my mesh? I'll keep doing things until I find the answer on my own too. Thanks for any help, again.

(Also I've learned a fair bit about lighting now)

[Graham.]

So I've tried with FBX export from 3d studio max. The exporter lib is dated a full version, and I get a warning. But whatever. I can fix that later. I see the mesh in my level if I drag/drop from the content browser. But I can't spawn it from code. ... I mean I can spawn the actor but the mesh doesn't show up (the one from 3ds). So the problem continues.


---

excuse me, the fbx models show up fine. they were just placed wrong b/c of a bad pivot - my first one! ... learn by error.

[Graham.]

and it works with the fbx.... yo. wtf? I guess converting from brush to mesh requires an extra step to make it move. I don't know what setting to check - but tricky. from now on, it's 3ds only, boiyaaas.