Mapping flexibility
Moderator: Moderators
Mapping flexibility
Hello. I'm a modeler who has taken interest in the spring engine. Particularly, in the area of mapmaking. I have a few questions regarding the flexibility of the mapmaking area. Keep in mind, I do realize and understand the ingenious idea of using a texture map alone to create terrain.
I will list my questions. Please, answer them in order.
1. Can I import a static mesh into a map and use it as a walkable piece of terrain? (Like a bridge.) This would allow me to make "demigod" style maps with giant chasms.
2. Can I define variables such as rain, snow, and other environmental effects?
3. Is there any way to delete segments of terrain via alpha channels? Or any other means of doing it?
4. Can I import particle systems such as clouds and waves crashing against rocks?
5. Can imported static meshes be animated?
6. Can different areas of the map have different weather effects? (No rain under a bridge by means of simply raising the rain on top of it.)
7. Can there be different patches of water on the map? (A plateau with a lake and a waterfall.)
8. I plan on using Mudbox to make my map, then generate a height map from the model I make. I also plan to paint the texture onto the model then export it. All in Mudbox. Is there any issues with this approach?
9. (This one is a long shot.) If I can make static meshes walkable, can I make them move with units on them? (A lift system or something similar.)
10. Can I rig a "death zone"? Where if a a unit enters the zone, it dies? (Lava, poison, etc.)
I'd like to see some maps that are more than just land. First I need to know if I can even make one.
CLOSING NOTE: I just thought of a new trick. What if I alphad out the terrain around an imported static mesh, and then had the static mesh appear slightly about the ground within it? That way, it would appear to be walking on the mesh, while it is in fact walking on the terrain concealed beneath it. Would this work?
I will list my questions. Please, answer them in order.
1. Can I import a static mesh into a map and use it as a walkable piece of terrain? (Like a bridge.) This would allow me to make "demigod" style maps with giant chasms.
2. Can I define variables such as rain, snow, and other environmental effects?
3. Is there any way to delete segments of terrain via alpha channels? Or any other means of doing it?
4. Can I import particle systems such as clouds and waves crashing against rocks?
5. Can imported static meshes be animated?
6. Can different areas of the map have different weather effects? (No rain under a bridge by means of simply raising the rain on top of it.)
7. Can there be different patches of water on the map? (A plateau with a lake and a waterfall.)
8. I plan on using Mudbox to make my map, then generate a height map from the model I make. I also plan to paint the texture onto the model then export it. All in Mudbox. Is there any issues with this approach?
9. (This one is a long shot.) If I can make static meshes walkable, can I make them move with units on them? (A lift system or something similar.)
10. Can I rig a "death zone"? Where if a a unit enters the zone, it dies? (Lava, poison, etc.)
I'd like to see some maps that are more than just land. First I need to know if I can even make one.
CLOSING NOTE: I just thought of a new trick. What if I alphad out the terrain around an imported static mesh, and then had the static mesh appear slightly about the ground within it? That way, it would appear to be walking on the mesh, while it is in fact walking on the terrain concealed beneath it. Would this work?
Re: Mapping flexibility
1) You cannot walk on meshes, only the map. However, there's tricks to have bridges over giant chasms. Here I used voidwater, and draw cliffs, bridges, and tunnel tops mesh with OpenGL Lua, and used your closing note to make the bridge walkable.
2) The map format itself only has tag for the cloud density in the background sky. However, some mappers are bundling Lua files into their map to add rain, snow, fog effect into their map. I'd say see with Smoth, but he rage-quitted the forum.
3) Beherith found a strange bug that allowed that. That's the kind of trick that doesn't seem reliable though. I'd advise to instead use disable rendering of ground under 0 with voidwater SMD tag, or disable the whole terrain rendering with Spring.SetDrawGround(false).
4) Can you write the cloud and waves particle systems yourself? Or at least hackjob it from the existing particles systems?
5) No. You can use live units belonging to the Gaia team (a special team that is always here, and represent the map units). Just set them to neutral with very other team. If the animation is simple enough, you can also write directly in the gadget.
6) Only if you are able to modify the existing weather effects gadget to do so.
7) Definitively no. There's only one water level per map.
Sounds good. Don't forget to check what are dimensions of map source files.
9) No. Meshes are not walkable, and Spring doesn't support walking on moving stuff. If all you want is a lift, you can however disable the normal walking and force-move the units with MoveCtrl.
2) The map format itself only has tag for the cloud density in the background sky. However, some mappers are bundling Lua files into their map to add rain, snow, fog effect into their map. I'd say see with Smoth, but he rage-quitted the forum.
3) Beherith found a strange bug that allowed that. That's the kind of trick that doesn't seem reliable though. I'd advise to instead use disable rendering of ground under 0 with voidwater SMD tag, or disable the whole terrain rendering with Spring.SetDrawGround(false).
4) Can you write the cloud and waves particle systems yourself? Or at least hackjob it from the existing particles systems?
5) No. You can use live units belonging to the Gaia team (a special team that is always here, and represent the map units). Just set them to neutral with very other team. If the animation is simple enough, you can also write directly in the gadget.
6) Only if you are able to modify the existing weather effects gadget to do so.
7) Definitively no. There's only one water level per map.
Sounds good. Don't forget to check what are dimensions of map source files.
9) No. Meshes are not walkable, and Spring doesn't support walking on moving stuff. If all you want is a lift, you can however disable the normal walking and force-move the units with MoveCtrl.
Re: Mapping flexibility
As for ten, yes with lua, and without lua you can make all water in a map toxic with damage over time.
Re: Mapping flexibility
About 3: it only works with old renderer atm with shadows off. But the SSMF renderer, in progress by the esteemed Kloot supports this.
10: yes.
Closing:
Yes, if you use ssmf renderer (needs gfx card supporting shader model 3)
Could I please have a look at the stuff you made so far? Im really interested in all new mapping ideas :)
10: yes.
Closing:
Yes, if you use ssmf renderer (needs gfx card supporting shader model 3)
Could I please have a look at the stuff you made so far? Im really interested in all new mapping ideas :)
Re: Mapping flexibility
On a related note, ive been thinking about the possibility of rendering a diff heightmap than the real underlying one... would allow for some nice tricks at the cost of losing map deformation.
Re: Mapping flexibility
I've done a gadget that disable terrain rendering then draw its own fake terrain with OpenGL Lua. Try this mod, through a lobby. My goal was more to make the generated heightmap and the generated texture rendering match, but there's some bits around the edges where units can sink through the texture.
Re: Mapping flexibility
when and why?zwzsg wrote: I'd say see with Smoth,[/b][/url] but he rage-quitted the forum
Re: Mapping flexibility
This is definitely one of the more helpful forums I've ever been on.
So, while I can't make static meshes walkable, I can hide it out with Lua.
And, I assume you can make zones that units can't walk or build on.
So, what if I made a MASSIVE model. This model would be the level. It would be a sort of space station. And, you could walk on a bunch of ramps. All on the same plane. And, it would be in space, so I would use the space sky texture. I noticed there were some nice asteroid maps somewhere around here that had a space texture.
Thereby, I would just model my entire map in either 3ds max 2010, or Maya 2010, and make the appropriate pathing maps?
If this is possible, I have many mapping plans. Another plan is to make a sci fi city (at night) with a bunch of platforms way up in the sky to walk on.
Of course, these maps would end up with a rather large filesize. But, they would look spectacular.
And Beherith, I actually haven't mapped for anything in a while. But I am a modeler, so I can send you pics of some random models if you want.
So, while I can't make static meshes walkable, I can hide it out with Lua.
And, I assume you can make zones that units can't walk or build on.
So, what if I made a MASSIVE model. This model would be the level. It would be a sort of space station. And, you could walk on a bunch of ramps. All on the same plane. And, it would be in space, so I would use the space sky texture. I noticed there were some nice asteroid maps somewhere around here that had a space texture.
Thereby, I would just model my entire map in either 3ds max 2010, or Maya 2010, and make the appropriate pathing maps?
If this is possible, I have many mapping plans. Another plan is to make a sci fi city (at night) with a bunch of platforms way up in the sky to walk on.
Of course, these maps would end up with a rather large filesize. But, they would look spectacular.
And Beherith, I actually haven't mapped for anything in a while. But I am a modeler, so I can send you pics of some random models if you want.
Re: Mapping flexibility
To the contrary.Mr. Bob wrote:Of course, these maps would end up with a rather large filesize.
Re: Mapping flexibility
Been asking for that for months now... would definitely useOn a related note, ive been thinking about the possibility of rendering a diff heightmap than the real underlying one... would allow for some nice tricks at the cost of losing map deformation.
That's been done (well, except for the "night" part:Another plan is to make a sci fi city (at night) with a bunch of platforms way up in the sky to walk on.
The problem is mixing platforms with non-platforms, and having an invisible heightmap would make that a considerably easier issue to deal with, but it's not in the engine at this time.
- Attachments
-
- screen00026.jpg
- (134.86 KiB) Downloaded 3 times
Last edited by Argh on 11 Mar 2010, 18:33, edited 1 time in total.
Re: Mapping flexibility
It wouldn't be that bad?zwzsg wrote:To the contrary.Mr. Bob wrote:Of course, these maps would end up with a rather large filesize.
True, I guess since the there would be no height map, the height map texture could be very small.
I get started on the model as soon as I can.
Oh, and one more question. Seeing as how you clearly can't have a LOD for a model that encompasses the entire level, what poly range would be appropriate?
EDIT: Argh, I was planning something further up. Think coruscant from Star wars. You won't even be able to see the ground. Therefor, all the ground is not rendered. : )
Last edited by Mr. Bob on 11 Mar 2010, 18:36, edited 1 time in total.
Re: Mapping flexibility
@Mr. Bob
You would lose some engine-support that the landscape provides like, afaik, shadows, scorch-marks, etc.
And I think Argh was begging for the same thing - invisible terrain that was at a different elevation from real terrain. This would make bridges much more doable.
You would lose some engine-support that the landscape provides like, afaik, shadows, scorch-marks, etc.
And I think Argh was begging for the same thing - invisible terrain that was at a different elevation from real terrain. This would make bridges much more doable.
Re: Mapping flexibility
I thought the engine rendered shadows upon static meshes. Plus, the ground would be at the same level as the static mesh. It would just be not rendered.Pxtl wrote:@Mr. Bob
You would lose some engine-support that the landscape provides like, afaik, shadows, scorch-marks, etc.
And I think Argh was begging for the same thing - invisible terrain that was at a different elevation from real terrain. This would make bridges much more doable.
Would it still not work? It would be rather sad if it doesn't.
Re: Mapping flexibility
I'm not sure about the shadows... you'd definitely lose all the other map-recolouring modes though, like the various F1-F5 information maps, the radar/sight/jammer map.
Re: Mapping flexibility
Wheeeee. I think we'd all better back up a minute.
1. Heightmaps must still be present, even if you hide the level geometry. You can use a zero-height map, then manipulate it with code, but (at present) there is no code that will automatically shape it to a model. I was working on that problem, but I've had to set it aside for now.
So, if you want to try the giant-model approach... the best way to go about it is to build a heightmap from your mesh, i.e., render the mesh with a shader or other techniques to produce a 16-bit representation of the mesh from above. That will be be pretty tricky, but possible. Talk to Picasso about that, he's used a technique like this many times, to match static renders with heightmaps derived from 3D objects.
2. If you use a single mesh, instead of breaking it up into smaller pieces tied to POV in some way, you will face pretty severe restrictions on polycount- no more than 64K triangles or so. But the biggest problem is that it will be utterly static, and (unless you're an OpenGL wizard) it will have to use one texture.
The approach I used got around those problems by breaking the level into platforms that can all respect POV and keep polycount in a typical scene to a low level, whilst allowing me to be generous about textures, so that the total scene could feel detailed enough.
3. The reasons I want invisible heightmap support are that:
A. We can then mix terrain types- bridges still won't be real bridges (you can't pass beneath them) but they'd look like it if you drove units over them.
B. Stuff like map-marks would be supported (that's the biggest flaw with my "platform world" map- ground flashes, etc. aren't supported).
There is no problem with putting a really huge Unit (geometry-wise) at 0,0, or centering it at the map center, and forcing OpenGL to draw it all the time. I don't know whether it can be forced to draw shadows if its center is far enough from the POV, though- I've never tried a really large test of that.
But regular Spring maps aren't just arbitrary meshes; they're actually huge bitmaps. Everything you're talking about it wanting to do is pushing what's currently cutting-edge.
1. Heightmaps must still be present, even if you hide the level geometry. You can use a zero-height map, then manipulate it with code, but (at present) there is no code that will automatically shape it to a model. I was working on that problem, but I've had to set it aside for now.
So, if you want to try the giant-model approach... the best way to go about it is to build a heightmap from your mesh, i.e., render the mesh with a shader or other techniques to produce a 16-bit representation of the mesh from above. That will be be pretty tricky, but possible. Talk to Picasso about that, he's used a technique like this many times, to match static renders with heightmaps derived from 3D objects.
2. If you use a single mesh, instead of breaking it up into smaller pieces tied to POV in some way, you will face pretty severe restrictions on polycount- no more than 64K triangles or so. But the biggest problem is that it will be utterly static, and (unless you're an OpenGL wizard) it will have to use one texture.
The approach I used got around those problems by breaking the level into platforms that can all respect POV and keep polycount in a typical scene to a low level, whilst allowing me to be generous about textures, so that the total scene could feel detailed enough.
3. The reasons I want invisible heightmap support are that:
A. We can then mix terrain types- bridges still won't be real bridges (you can't pass beneath them) but they'd look like it if you drove units over them.
B. Stuff like map-marks would be supported (that's the biggest flaw with my "platform world" map- ground flashes, etc. aren't supported).
The main terrain renderer does LOD and tessellation on the fly; the platform map was achieved by using Unit geometry.I thought the engine rendered shadows upon static meshes. Plus, the ground would be at the same level as the static mesh. It would just be not rendered.
There is no problem with putting a really huge Unit (geometry-wise) at 0,0, or centering it at the map center, and forcing OpenGL to draw it all the time. I don't know whether it can be forced to draw shadows if its center is far enough from the POV, though- I've never tried a really large test of that.
But regular Spring maps aren't just arbitrary meshes; they're actually huge bitmaps. Everything you're talking about it wanting to do is pushing what's currently cutting-edge.
Re: Mapping flexibility
map size comes from the ground texture mainlyMr. Bob wrote:It wouldn't be that bad?zwzsg wrote:To the contrary.Mr. Bob wrote:Of course, these maps would end up with a rather large filesize.
for fuckwinArgh wrote:invisible heightmap
Re: Mapping flexibility
Hmm. That's not good. Basically, unless you designed a mod specifically for it, it would never look right.Pxtl wrote:I'm not sure about the shadows... you'd definitely lose all the other map-recolouring modes though, like the various F1-F5 information maps, the radar/sight/jammer map.
I might try it anyway. While terrain deformation and recoloring will be lost, at least it will look great.
Re: Mapping flexibility
1. Hmm. Ok. But, I was planning on having only one height throughout the level.Argh wrote:Wheeeee. I think we'd all better back up a minute.
1. Heightmaps must still be present, even if you hide the level geometry. You can use a zero-height map, then manipulate it with code, but (at present) there is no code that will automatically shape it to a model. I was working on that problem, but I've had to set it aside for now.
So, if you want to try the giant-model approach... the best way to go about it is to build a heightmap from your mesh, i.e., render the mesh with a shader or other techniques to produce a 16-bit representation of the mesh from above. That will be be pretty tricky, but possible. Talk to Picasso about that, he's used a technique like this many times, to match static renders with heightmaps derived from 3D objects.
2. If you use a single mesh, instead of breaking it up into smaller pieces tied to POV in some way, you will face pretty severe restrictions on polycount- no more than 64K triangles or so. But the biggest problem is that it will be utterly static, and (unless you're an OpenGL wizard) it will have to use one texture.
The approach I used got around those problems by breaking the level into platforms that can all respect POV and keep polycount in a typical scene to a low level, whilst allowing me to be generous about textures, so that the total scene could feel detailed enough.
3. The reasons I want invisible heightmap support are that:
A. We can then mix terrain types- bridges still won't be real bridges (you can't pass beneath them) but they'd look like it if you drove units over them.
B. Stuff like map-marks would be supported (that's the biggest flaw with my "platform world" map- ground flashes, etc. aren't supported).
The main terrain renderer does LOD and tessellation on the fly; the platform map was achieved by using Unit geometry.I thought the engine rendered shadows upon static meshes. Plus, the ground would be at the same level as the static mesh. It would just be not rendered.
There is no problem with putting a really huge Unit (geometry-wise) at 0,0, or centering it at the map center, and forcing OpenGL to draw it all the time. I don't know whether it can be forced to draw shadows if its center is far enough from the POV, though- I've never tried a really large test of that.
But regular Spring maps aren't just arbitrary meshes; they're actually huge bitmaps. Everything you're talking about it wanting to do is pushing what's currently cutting-edge.
2. Don't worry. I can work my magic when it comes to polies and textures.
Yeah, I am probably asking for too much. Well, I'll work on a regular terrain based map first just to get the feel of everything.
Thanks for all your help guys, and for answering the bucketload of questions.
Re: Mapping flexibility
F1 works, at least on the minimap. The others don't, if you hide the map geometry IIRC.
Oh well, show people that there's metal by having a metallic area, or a flashing sign that says, "hey, metal here nubs".
You could use multiple Units as "tiles", and avoid a lot of these problems. I thought about doing that, to replace the underlying surface of one of my maps, but haven't gotten around to testing performance of the technique. I suspect it will perform very well vs. SMF... for that case.
Oh well, show people that there's metal by having a metallic area, or a flashing sign that says, "hey, metal here nubs".
Oh... that changes stuff, quite a bit. We're all imagining 3D spaces- ramps, loop-de-loops... the usual stuff that people seem to think we can just wave magic wands and do1. Hmm. Ok. But, I was planning on having only one height throughout the level.
You could use multiple Units as "tiles", and avoid a lot of these problems. I thought about doing that, to replace the underlying surface of one of my maps, but haven't gotten around to testing performance of the technique. I suspect it will perform very well vs. SMF... for that case.
Re: Mapping flexibility
So in other words, to summarize, it is possible, but it would be hard to do, and you would lose quite a bit of terrain features, like shadows, re-coloration, and deformation.
Sounds like a challenge. I'll start after I get finished with a few regular terrain based maps.
Sounds like a challenge. I'll start after I get finished with a few regular terrain based maps.