| Author |
Message |
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
|
sweatervest
Ree-Yees
Joined: 22 Apr 2008
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
|
The MAZZTer
Death Star
Joined: 25 Sep 2003
|
 Posted: May 28, 2008 20:22 Post subject: |
    |
|
Well Source allowed you to place archi that appeared outside the normal level 16x bigger but inside the skybox
This allowed you to make the level transition into the archi instead of ending right at a skybox texture wall. Instead of working with large structures in the editor outside your level, you could make them 16x smaller in a skybox (which is easier to work with from the editor). Then all you have to do is put your simple sky brushes in your level and the extra archi "outside" is rendered properly even if the player moves around. It also keeps things simpler so you don't have to put special brushes in to keep players out of the extra archi (well normally they shouldn't get there anyway if your level design is good enough but you'd be surprised how far explosions can fling you without dying in TF2)... since the extra archi is over in a skybox they can't leave the level for it anyway.
_________________
http://www.mzzt.net/ | I am a respectable admin with a respectable sig. |
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
|
Emon
Ree-Yees
Joined: 10 Aug 2007
|
| Posted: May 29, 2008 00:28 Post subject: |
|
|
MZZT is describing a portal skybox of sorts, they've been around for years in various Q3-based games. Elite Force II used them rather prominently.
|
|
The MAZZTer
Death Star
Joined: 25 Sep 2003
|
| Posted: May 29, 2008 01:53 Post subject: |
|
|
Well I didn't notice it in Elite Force 2/Q3 because you don't tend to noclip and fly around a lot like you do in Garry's Mod... so there... >_>
_________________
http://www.mzzt.net/ | I am a respectable admin with a respectable sig. |
|
sweatervest
Ree-Yees
Joined: 22 Apr 2008
|
|
Jon`C
Ree-Yees
Joined: 16 May 2008
|
| Posted: May 29, 2008 21:18 Post subject: |
|
|
DF does support 3DOs. You really wouldn't need very much to pull off some fairly modern-looking effects - 3DOs, sectors and maybe a JK-style ceiling sky would do it. Plus it's a safe guess to assume that lucius is already using stencils for skies so it's not an especially huge leap to go from what's currently being rendered to something like what you guys are talking about.
|
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
| Posted: May 30, 2008 17:02 Post subject: |
|
|
The low damage and high damage sector flags are nice, but it'd be nice if we could instead choose how much damage a sector did per second and whether or not a gas mask could protect you.
Also, I have a question - in WDFUSE there are 4 CUSTOM event_mask and event bits; are those the only usable custom events, or can you manually use higher number bits for even more custom events? If you can't, then can you please add a few more, just for the really really complex elevators?
From what you've told us before, I assume we will be able to tweak a weapon's scripted behavior, right? Such as changing the fire rate, damage, use of the "blast" flag for trigger events, and ammo type?
EDIT: Also, the projectile behavior, such as gravity, targeting, animation frames, etc.?
|
|
sweatervest
Ree-Yees
Joined: 22 Apr 2008
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 31, 2008 08:33 Post subject: |
|
|
sweatervest wrote:
Jon`C wrote:
DF does support 3DOs. You really wouldn't need very much to pull off some fairly modern-looking effects - 3DOs, sectors and maybe a JK-style ceiling sky would do it. Plus it's a safe guess to assume that lucius is already using stencils for skies so it's not an especially huge leap to go from what's currently being rendered to something like what you guys are talking about.
Oh yeah the 3DOs, I forgot we're not working with the Doom engine here.
How do other similar engine ports do skyboxes (Doomsday, WinRott, etc.)? I would think since we're now using actual 3D geometry for rendering the addition of fully flexible skyboxes would be almost trivial.
I already talked about how I was planning on doing the optional "skybox":
lucius wrote:
Here is my plan for skyboxes:
I'll add a "skybox camera" logic that will stay in one place (where ever you place the dummy object it's attached too) and where the camera direction matches the player camera direction. Then anything that camera can see from that view is rendered as the current sky. So to add a cubic skybox: make a cubic sector, place the skybox camera in the center and place your 6 textures on the walls. Of course, since this will be a logic attached to an object, nothing says that the camera has to be stationary... And you can make any sort of sectors or geometry as normal, so you can have 3D elements in your skybox, scrolling textures, or whatever you can normally make in the engine.
Of course this is optional, standard DF skys will be available as well.
and
lucius wrote:
The only difference in this case is that the scale factor will be variable. But actually allowing geometry (and in this case Sectors) that are in the skybox, you open up all sorts of cool things. The source games had some cool backgrounds thanks to this trick, like you mentioned. You could even, for example, have the skybox camera moving along a path (using scripting) so it appears that your entire level is moving. Think of a level where you're on a ship and the ship is approaching a planet or passing through an asteriod belt for instance. Anyway having a scale factor would make this stuff possible without having to have rediculously large areas of your level dedicated to the skybox.
The_Mega_ZZTer said that the first description is similar to what Source does and then it went on from there... Anyway I'm not trying to emulate Source's sky system, it just so happens to be similar - there are only so many ways to do stuff like this and make it as flexible as I want.
Anyway this means that the "sky box" can have geometry (3DOs), sector geometry, sprites, waxes and more. It also means that, while by default the sky camera would be fixed in one place, if you attach it to a moving object or move it's parent using scripting you can move and rotate the "sky box" because this affects the sky box camera.
So you could, for example, have a level take place in a ship and have the skybox camera follow a track (which could be curved) and make it appear that the ship is going through an asteriod field or approaching a planet. This would be done by modeling an asteriod field and planet, then having the camera move through it in interesting ways. This makes it appear that the entire level is "moving" through the asteriod field, but in reality only the skybox camera is moving. If you set the camera scale appropriately this doesn't even have to take up a lot of space in your level, you can scale it up 16x or whatever like The_Mega_ZZTer suggested. I'm planning on doing some showcase levels eventually to show off some of the new features like this later, that should help eventually.
Does this make my plans more clear? Any comments on these ideas?
Of course DF style skys are implemented differently, which type of sky a level uses will have to be a level setting. And like DF, you could actually have more then 1 skybox per level by allowing each sector to reference a specific skybox camera...
_________________
DarkXL....http://darkxl.wordpress.com |
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
| Posted: May 31, 2008 14:49 Post subject: |
|
|
So I'm assuming we set the ceiling texture (or wall or floor texture) to the Skybox Camera's name to get a sky, right? And we're gonna use VUEs to move the cameras, right? It'd be really useful if we had an INF command to play a particular VUE on a particular object, that would help if we wanted to, for example, have a ship start out just stationary and then start moving after activating a switch.
One thing that bugged me in DF was that when we shot at a sky, the projectile just disappeared when it hit the "ceiling" height. What will you do about this? Will the projectile enter the skybox sector and collide with skybox geometry?
Also, will 3D objects have collision logic?
|
|
sweatervest
Ree-Yees
Joined: 22 Apr 2008
|
| Posted: May 31, 2008 15:40 Post subject: |
|
|
sheepandshepherd wrote:
One thing that bugged me in DF was that when we shot at a sky, the projectile just disappeared when it hit the "ceiling" height. What will you do about this? Will the projectile enter the skybox sector and collide with skybox geometry?
Unreal suffered from that too, where a projectile would either disappear or explode on the invisible surface. The problem with transporting stuff to the skybox, in that game at least, is that since skyboxes can be arbitrarily large or small (though always creating the illusion of being very large), there is no telling how big the projectile or the resulting explosion, etc. will be when rendered in the skybox, and you could easily end up with a planet-sized rocket for example.
Also, one would have to calculate where the projectile gets transported to in the skybox. If it came out of the camera it wouldn't look right at all (for example taking up the entire sky for the first split-second), and in fact making the transition smooth would actually require calculating where, relative to the player, the projectile hit a ceiling, so that the projectile will appear at the same screen coordinates when it moves to the skybox. In a multiplayer setting, each client would need to be looking at their own skyboxes or only one player would see a projectile move smoothly from the level to the skybox.
In fact, making that look correct would be impossible, because skyboxes are rendered as if they are infinitely far away (scenery doesn't move relative to screen) so the projectile would go from being a finite distance from the player to being at infinity with the skybox. For example, if you shoot a projectile while strafing the projectile would move sideways on the screen as you strafe away from it, but as soon as it hits the skybox it will all of sudden start scrolling differently because stuff in the skybox doesn't move past you like the projectile was.
Here is an idea. When a projectile hits a "sky" surface, disable all collision detection and just let the projectile fly out through the level, getting further and further away, but have it only renderend on "sky" surfaces. That way the projectile appears to fly out to infinity while behind all of the level geometry but in front of the skybox.
|
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
| Posted: May 31, 2008 16:14 Post subject: |
|
|
Yeah, it's a really problematic business . . . in Prey, you could shoot through the portals and the projectiles would appear correct . . . if lucius made the ceiling surface act like a portal to the skybox, that might possibly make things easier, similar to shooting through simple adjoins . . . I don't know how we'll deal with the size problem though. I don't think multiple players will be supported in DarkXL anytime soon, but if lucius decides to someday include that, we'll need to deal with that as well.
Let me clarify what I mean by skybox portals:
The ceiling of a sector will always (for now) be a flat polygon. Imagine that same polygon shape somewhere in the skybox. A projectile entering coordinates XYZ in the sector's ceiling will appear in the same coordinates on the polygon portal in the skybox, with the same speed and trajectory. After that, it wouldn't be too hard to implement projectile scaling. Now the only problem with that method is how to have multiple sectors use the same skybox . . . unless each sector has its own ceiling polygon in the skybox, connected at the same spots as the actual sectors . . .
Ughhh, confusing stuff 
|
|
lucius
DarkXL Developer
Joined: 17 Feb 2008
|
| Posted: May 31, 2008 19:19 Post subject: |
|
|
sheepandshepherd wrote:
So I'm assuming we set the ceiling texture (or wall or floor texture) to the Skybox Camera's name to get a sky, right? And we're gonna use VUEs to move the cameras, right? It'd be really useful if we had an INF command to play a particular VUE on a particular object, that would help if we wanted to, for example, have a ship start out just stationary and then start moving after activating a switch.
One thing that bugged me in DF was that when we shot at a sky, the projectile just disappeared when it hit the "ceiling" height. What will you do about this? Will the projectile enter the skybox sector and collide with skybox geometry?
Also, will 3D objects have collision logic?
While VUEs would be handy, I was also thinking of controlling the camera through scripting as well. Of course if all you want is a 3D sky or skybox, then you will just use the default logic.
And yes, simply the camera name would be needed to assign a skybox camera to a surface.
As for what happens when projectiles hit the sky polygons, I think I'll leave it the way DF does it at first. Maybe later we can revisit this issue.
_________________
DarkXL....http://darkxl.wordpress.com |
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
| Posted: May 31, 2008 19:36 Post subject: |
|
|
Of course, scripting is even better than VUEs. We could just use scripting for any moving object and not need VUEs anymore . . . one thing that would help is being able to place points or lines on a map for things such as moving objects or AI scripts.
Also, in the future, you may want to consider the method I talked about above for skyboxes, using portals instead of just single-point cameras . . . that would probably make projectiles and other problems easier to deal with.
|
|
Jon`C
Ree-Yees
Joined: 16 May 2008
|
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
|
sweatervest
Ree-Yees
Joined: 22 Apr 2008
|
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
|
Burning Gundam
Kell Dragon
Joined: 28 Sep 2003
|
| Posted: Jun 02, 2008 02:46 Post subject: |
|
|
Amidst reading all of the new features it suddenly occurred to me that some new form of an editor is going to have to be released.
_________________
I don't think outside the box... I customize it. |
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
| Posted: Jun 02, 2008 02:54 Post subject: |
|
|
Yeah. I can't do it. I wonder if we could just contact Yves Borckmans and the other WDFUSE authors for some sort of ancient source code to build on . . . or better, CDark by Mattias Welander . . . never even tried that one, but building on one of those would be a whole lot better than creating something from scratch . . .
|
|
sweatervest
Ree-Yees
Joined: 22 Apr 2008
|
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
|
The MAZZTer
Death Star
Joined: 25 Sep 2003
|
|
sweatervest
Ree-Yees
Joined: 22 Apr 2008
|
| Posted: Jun 02, 2008 17:10 Post subject: |
|
|
Perhaps at some later time lucius, if he wants, can release the DarkXL source to a few developers to help build a new level editor. Modding the engine to edit rather than play seems easier than building one from scratch.
|
|
sheepandshepherd
Trandoshan
Joined: 01 Apr 2008
|
| Posted: Jun 02, 2008 17:22 Post subject: |
|
|
Yeah, a lot of the newer editors seem to do that . . . If any of you've ever played Armada 2, its "editor" is completely in-game, and you can even switch between them during gameplay with a certain hotkey that I forgot . . . Ctrl+A, I think . . .
|
|
|
In UnrealEd you could put any kind of geometry, actors, or whatever (for example I made a level way up in the sky and put some of the bird pawns in the skybox so you could see them flying way off in the distance) and it would render whatever the skybox actor saw, so you could scale down all the geometry/objects and it wouldn't change what the skybox looked like, but then again DF doesn't have polygons...