Look at this bleeding mess!

Me and a freind started learning Unreal ED yesterday and I thought, "What better way to learn a engine than port a map! And what map better to port than one that I know every inch of!"

So resulting in many annoying crashes and terrible imports is...





Obviously far from perfect but hey, It's a start. :iamafag:
I learned a lot about the engine in 1 day.

I need some help with this though. I'm having problems.


1. How do I make a (proper) detail map in a shader. I did a crappy one with the ADD function but it looks terribad. I need to be able to make white alpha show one detail map on the diffuse texture and the black alpha show a different detail map on the diffuse texture. In the same way that halo does it.

2. How do I take a pre-exsisting cubemap and import it into Unreal ED and how do I use it.

3. Can you make a bumped-cubemap? Basically will normal maps work with a cubemap reflection on them.

4. I imported the mesh of collision from halo but there are random holes and bugs with it. The only thing I've done with it in the Unreal Ed is re-scale it. I don't see why the collision is so broken in some places.

That's all I need for now. Thanks.

I think for your detail maps you multiply one tiled detail map by the diffuse alpha then multiply the diffuse by the result, and do the same for the other detail map but inverting the diffuse alpha first.

Answers to the following numbers ...

2: You can use existing Cubemaps that have already been made , for instance the Chiefs visor , you just click create cube map material and go from there :P

4: UT3 is not good for importing collision such as that , it has problems , it uses simple shape collision to accurate get everything right , the only solution is to build the level entirely in UT3 out of brushes like i am having to do with one of my levels now , to get completely accurate collision.

You can turn on normal collision for UT3 by just unchecking the "Use standard box collisiion" or whatever in the static's options in the generic browser. Give that a try.

from experiance llama just clicking that gives it a collision box , nothing more , you could use per poly collision which would be the most accurate , only problem is , it would not work atall with actors inside the game world.

The collision is mostly fine. It's just very specific spots that are fucked up. Usually just a hole or a small invis wall.

Quote:

---

Originally Posted by SonicXtreme

from experiance llama just clicking that gives it a collision box , nothing more , you could use per poly collision which would be the most accurate , only problem is , it would not work atall with actors inside the game world.

---

No, by default it's checked which gives you box collision. If you uncheck it then it gives you per poly collision.

http://www.hourences.com/book/tutorialsue3modeling1.htm

# Collision made in an external package

All you need to do is to give the mesh you wish to use as collision the prefix UCX. Example: if the regular mesh is named Tree, the collision for Tree should be named UCX_Tree. Select both, and export both together into the same ASE file. Upon import the engine will recognize the UCX mesh, and assign it as collision model. It will not show up in the Generic Browser.

((I just use per-poly collision for -- well -- just about everything so meh)) -- If you're having some problems with collision still -- re-import the ASE and see if 3DS Max threw up when exporting it.

*****

Bumped Cubemaps work... that's how water ripples are made.



*****

Only Cubemap I successfully did was done by importing the panels separately.

Cubemaps can be used just like any other texture -- they can be attached to any node that accepts textures... but I find it IS a little more than slightly glitchy in UnrealEngine3 when I tried it. But, results may vary.

So yes, when they work, you can have it desaturated and multiplied into a opacity map, attached directly to the emissive channel, or -- whatever you can do with a regular texture...

Just make sure you have it attached to some sort of vector transform so that the engine knows -- for instance -- to pan the cubemap when you rotate the camera or something.



Attached the cubemap's UVs to a rotator that spins around the yaw (to make the entire sky slowly turn... give the illusion of moving clouds)... then the rotator was attached to the camera vector so when the camera moved, the sky would appear fixed in place. (Ignore the multiply of the camera vector by 1,1,1... that does nothing)

But yeah, that entire thing in no way needs to be connected to emissive... that was just what I needed for a Skybox.

http://img198.imageshack.us/img198/3231/46155872.jpg
http://img200.imageshack.us/img200/5922/39764123.jpg

^ thats for Cube maps

As for the collision , importing an entire BSP has its problems , when i imported alot of my ASEs , i found that its better creating your own more simplistic version of the collision for what ever it is your doing , otherwise you`ll encounter lots of problems.

I've made a lot of progress. I'm getting better at the shader creation system. I plan on remodeling a lot of parts in the collision UCX. That should clear up the bits that are messed up.

I still don't really understand how I take a halo cubemap that I have extracted and Import it into UT so that it is recognized as a cubemap and not as just another texture.

How I do it, and apparently how Sonic does it... is I load my 6 skybox faces as textures... then create a cubemap object... then load the 6 faces in the cubemap.

Note: Rotating/Reflecting the cubemap faces into place was a test of patience for me... tweak in Photoshop... reimport to UnrealEd... hope it doesn't crash... refresh the cubemap... repeat until correct.

Quote:

---

Originally Posted by Phopojijo

How I do it, and apparently how Sonic does it... is I load my 6 skybox faces as textures... then create a cubemap object... then load the 6 faces in the cubemap.

Note: Rotating/Reflecting the cubemap faces into place was a test of patience for me... tweak in Photoshop... reimport to UnrealEd... hope it doesn't crash... refresh the cubemap... repeat until correct.

---

^ exactly

When I clicked your images it said your account was suspended.

Quote:

---

This Account Has Been Suspended
Please contact the billing/support department as soon as possible.

---

Seems to be fixed now.

Also the map is really shaping up. It now greatly resembles BG. With the new custom sky and all. :iamafag:

I've also got it set up for testing almost so I think some modacity members who have UT3 need to get ready for a test.


-edit
I've got a more serious issue now. When I start a deathmatch or TDM match with bots I get a HUGE frame rate drop. It's fine when it's just me but when a bot is in the game my framerate drops to about 5.

Also they seem to get stuck in the base and have issues going up the ramp to the base.

*cough*


http://www.freewebs.com/infernosk8te...h_ingame_1.jpg
http://www.freewebs.com/infernosk8te...h_ingame_2.jpg

That is all.

Port revelations to ue3

I'll do it for 100.19 moneys.

you'll do it for free faggot

Quote:

---

Originally Posted by Inferno

-edit
I've got a more serious issue now. When I start a deathmatch or TDM match with bots I get a HUGE frame rate drop. It's fine when it's just me but when a bot is in the game my framerate drops to about 5.

Also they seem to get stuck in the base and have issues going up the ramp to the base.

---

propably because your map is one big mesh, and any light across the map, also gets rendered if you're not seeing it (but you're seeing the object it affects) you could also show your statistics to see where your performance loss is coming from (gpu/cpu/ram related etc)

as for the bots getting stuck, that's just a patching issue. hit P to show paths, and make sure your pathnodes are all properly linked together.
if it all seems fine, try scaling up your base just a bit, so they have less of a fit wondering if they can squeese themselved trough the openings.

It's possible that may be the problem with the framerate.
Can I just portal the map in UE3 or do I have to break up the mesh in max and re import as parts?

edit-

The map is only like 5k polys It shouldn't be to much of a problem for the engine to handle all at once.

The level auto portals its self , its because the whole thing is one big mesh like Neuro said.

it doesnt have to do with the polycount, it's got to do with the fact that everything (really eVERYTHING) has to interact with a single object, causing massive calculations on that single object. you should chop the map up into several pieces (mind you, you cant smooth across 2 objects, so you'll see a seam unless you make the seam planar (polygon on one side being planar with the polygon it lines up to on the other side of your seam.))

ineed again , Neuro is right , it has nothing to do with the polycount , like i said it auto portals and optimizes ingame unlike previous engines, its about huge calculations with a single object , indeed you shall have to cut it into sections.

Quote:

---

Originally Posted by neuro

it doesnt have to do with the polycount, it's got to do with the fact that everything (really eVERYTHING) has to interact with a single object, causing massive calculations on that single object. you should chop the map up into several pieces (mind you, you cant smooth across 2 objects, so you'll see a seam unless you make the seam planar (polygon on one side being planar with the polygon it lines up to on the other side of your seam.))

---

See inferno, I fucking told you!

Okay fuck.

Cliffs a separate mesh.

Both bases separate meshes.

The ground a separate mesh.



Would that work?

edit-

Better idea. What If I leave the visual mesh as 1 object but break up the collision meshes into many different objects. Would that do it?

Quote:

---

Originally Posted by Inferno

Okay fuck.

Cliffs a separate mesh.

Both bases separate meshes.

The ground a separate mesh.



Would that work?

edit-

Better idea. What If I leave the visual mesh as 1 object but break up the collision meshes into many different objects. Would that do it?

---

Nope... because a BIG (possibly even the biggest in your case) factor is light-object interactions.

Lets assume every player is firing their gun at the same time... that means you have 32 dynamic lights affecting the same mesh at the same time, plus the dynamic light of the flag, plus the dynamic light around every item pickup... etc.

If you cannot see an object... any light hitting that object is not calculated...

Quote:

---

Originally Posted by Inferno

Okay fuck.

Cliffs a separate mesh.

Both bases separate meshes.

The ground a separate mesh.



Would that work?

edit-

Better idea. What If I leave the visual mesh as 1 object but break up the collision meshes into many different objects. Would that do it?

---

More like split the cliffs up into several meshes , plus the floor , plus the bases split up the same , so its made of many parts, check Epics packs to see how its done , then do each section bit by bit.

But I don't want seems all over my ground mesh. :ohdear:

how about this then , do the ground as terrain instead of actual static mesh then , and then create everything else using static meshes , unless you just wanna make a more UT3 style one using all their stuff and the skybox from the timberland map for UT3 , that one was a good map.

That's possible but I would lose the UV's for the ground.

It seems that the more decimal points in a vertexes coordinates the more errors it causes in collision. I'm going to reduce all collision meshes to a maximum of 1 decimal in the cooridinates.

By this I mean. 134.32154 becomes 1.3 and 12.28 becomes 12.3.

This should fix all the collision problems.

aw, if you were going to port one you should have done infinity :-3

Quote:

---

Originally Posted by Ki11a_FTW

aw, if you were going to port one you should have done infinity :-3

---

I agree. Infinity would play well in big ctf matches.

Don't worry. Me and my freind have plans.

Expect to see lots more halo stuff in UE3 once we master the porting process.

So I'm working on optimization now. Here is my mesh and collision breakdowns.

Visual Mesh (10 parts)
http://dedi-servers.net/ftp/dmt/imag...hbreakdown.PNG

Collision Mesh (4 parts)
http://dedi-servers.net/ftp/dmt/imag...nbreakdown.PNG


I wanted to keep the collision as seamless as possible. Breaking down the collision is annoying as hell.

edit-
Bawwww I totally forgot to change the color of the bases. Both bases are separate meshes also.

when it comes to the bases, you'd propably be best off detatching stuff per smoothinggroup and element. you'll end up with alot of objects, but you'll end up with it running more efficient, since i'm guessing that's where most picke-ups and such would be (all of which have dynamic lights) cutting all of that up in seperate objects will help that alot (and save you alot of rendering when you're outside and dont see the inside)

thing is, iv you keep your base one thing.. when you look at it from the outside, you'll also render the inside, and thus the lights that are inside affecting the inside (but being rendered on the entire thing so the outside as well)