Portalized (GUI update)

[Praetor]

Not really disappointing at all. Seems like a rare case. Collision will only malfunction at the instant control passes from one side to the other. I was just making sure I understood.

[Aquatix]

I haven't seen your source code, so cannot know for sure, but I was just thinking - maybe it is not too difficult to implement - have you thought of creating a temporary "mimic" physical body at the other side of the portal? Synchronizing it with the base counterpart perhaps can do the trick. Surely, this would not be a primitive, but a convex hull, which you have to update according to what part of the object is "sticking out" of the portal. Also, pretty sure it must not be affected by gravity.
Hope it makes sense

[nullsquared]

Self-quote:

Big Note: Please note, however - I DO have a concept idea of recreating the dual-sided collisions with the benefit of my system. This is not the final release, and if I get my math right, you may just get the benefits from both systems in Portalized. I cannot guarantee you that it will work, but I will not say that it won't. Keep your fingers crossed .

I have to say but one thing. If this works out the way I'm planning for it to... this might turn into a full-blown portal simulator, where if you stick an object half way it will not only collide on both sides, but get pulled by forces and what-not (portal on wall and ceiling, an object half-way will eventually get sucked in due to the gravity "through" the portal).

(man, the power of NewtonGD, it's freaking amazing...)

[Praetor]

Yeah, create a ghost on each side of the portal, but don't allow collisions between those overlapping representations. Body1 is affected by forces on the original side of the portal, while Body2 is affacted by forces on the destination side. You can "glue" then together with a custom rigid joint in Newton. I'm sure this is slightly unstable though. It probably will blow up with moderate force applied, since removing that many DOFs in a joint is tricky. Worth a try though. There also might be better ways to stick the two bodies together (really stiff springs?).

[nullsquared]

Yeah, create a ghost on each side of the portal, but don't allow collisions between those overlapping representations. Body1 is affected by forces on the original side of the portal, while Body2 is affacted by forces on the destination side. You can "glue" then together with a custom rigid joint in Newton. I'm sure this is slightly unstable though. It probably will blow up with moderate force applied, since removing that many DOFs in a joint is tricky. Worth a try though. There also might be better ways to stick the two bodies together (really stiff springs?).

You nailed it, exactly what I'm doing.

Except:
- ghost is still only a graphical representation, the ghost body is there only for pushing or pulling (otherwise there may be small errors where physically it won't matter but you'll "see" it graphically)
- it's a bit hard to "glue" them due to the arbitrary portals... but newton's custom joints allow for it

Yeah, this'll probably work once I get it right...

[irishlostboy]

the posibilities of your portalized portal tech, combined with the dissorder gravity stuff, is pretty huge now. but its still just potential. what kind of game are you going for with this? it would be a good time to refine what you have to fit an overarching concept, rather than going nuts trying to get every game mechanic to work, then having to throw a lot of it out later to fit a good design. although your posibilities so far seem endless, the more you go wild with the tech, the more you are boxing yourself in on the design. so far, you will be very pushed to create level designes to fully utilize all the features you have without breaking the game.
have you a visual style in mind? (sci-fi, grunge industrial, cartoon etc.)
i am not a tech guy, i am an art and design guy, but i am very fond of your work so far, hense my questions/thoughts above.

[nullsquared]

The style is sci-fi.

-snip story-

This story is perfect, since I am absolutely crap at AI, and there won't be a need for AI in Portalized. Maybe in Portalized 2 or something, when you encounter the infiltrator. But first of all, lets just stick to Portalized 1 .

[nullsquared]

Just so you're all updated, I'd like to say some pretty-ness will indeed be added . I'm teaming up with Pelpix (from the [now dead] Exite forums) for textures and Jaanus for models (both from face punch) - super small team, active, easy to manage, really enthusiastic.

For example:

- the cube is normal mapped, specular mapped, diffuse mapped, and (baked) AO mapped (as Pelpix describes that Source² does)
- the metal grate, yes, doesn't tile - the AO map for it wasn't made for tiling, 'twas just a test
- floor, etc. Stuff will look pretty

I'm also planning on point-light variance shadow mapping.

Here's the original wall (so much detail can be obtained by such simple shaders, the wall here is shaded with a diffuse and specular map, that's it):

[kcbanner]

Looks great! Can't wait to see more artz

[nullsquared]

Looks great! Can't wait to see more artz

Heh, thanks .

BTW, working on shadows:

Next I'll be off to implement soft shadows (probably via variance shadow mapping, VSM).

[Kojack]

Hehe, that looks great.

I like the way the player looks through that portal, maybe changing his material to solid black to give it a stick figure appearance all the time would be cool.

[PolyVox]

Cool, so can shadows be cast through portals?

[nullsquared]

Cool, so can shadows be cast through portals?

As things are right now, nope. It's a feature on my long TODO list, but it's all the way on the end. Why? Well, to make light go through portals, there's really not much you can do other than duplicate the lights the same way everything else (camera, physics objects, etc.). Except that duplicating the lights would be a total nightmare (since you want them to only go through the portal, and not shine backwards into some other part of the level), and a killer for the performance.

Right now my TODO list is as so:
- fix materials (shadowing works great when I used 1 material, but it went bonkers with more - I'm guessing one of my materials is differing a bit and destroying the seamless-ness)
- make shadows soft (variance shadow mapping)
- finish portal physics (I never truly went around to implementing dual-sided stuff, I got it working as a sample, but I never actually implemented it with the portals)
- re-implement sound (I used to have sound in my older versions of the engine, but now it's just gone somehow :O)
- etc.

[Epimetheus]

When the game using this is released I will pay for it... and I generally don't buy pc-games since i'm a linux user. Oh and I love the cube design

[nullsquared]

It's going to be free, mate . Thanks .

[nullsquared]

Soft shadow mapping (in addition to point light shadow mapping) is in the works.

ps_2_x (low filtering radius): [ignore the frame rate, debug build]


arbfp1 (on SM4 hardware):



I've yet to get CG 1.5+ to work so I can use ps_3_0.

... and... Multiple materials!

[Chrispin]

That is one really nice looking game you have there. The shadows look pretty good, and not to mention, the models and textures look high quality. I just came to wonder how all of this might run on my system along with the portals. May I ask what your system specifications are?

[nullsquared]

I'm running on an 8800GTS, Athlon64 X2 3800+, and 1GB of ram. It should run pretty decently on most stuff... shadows and detail can always be reduced for lower end machines.

[Chrispin]

Well, I can tell you that I won't be playing at the speed you are. I have a Radeon 9800 and a Celeron 2.8 ghz single-core along with about 1.75 gb of RAM. I think I will be tuning the graphics settings a little lower, though I am sure I will run the portals and their iterations just fine.

By the way, I had a suggestion for the use of dynamic portals. Since dynamic portals can be placed anywhere, you will often be facing towards the rear end of them. Currently, I can see that you do not have a texture for that end. Wouldn't it be interesting to have a portal on both sides of these dynamic planes? The portals on the back sides would lead to each other, creating some interesting effects. For instance, if you vertically placed one dynamic portal in the middle of a room and vertically placed another dynamic portal in the middle of another room and then walked around one dynamic portal while simultaneously looking at it, you will see a 360 degree view of the other room. There is no telling how this would affect game performance, but this would probably be better than simply having a textured back for each portal.

[Chrispin]

This thread hasn't been updated for a while. Is this project still in the works?

[nullsquared]

Yeah, sorry for not really putting anything here.

Stuff is still in the works, but the 0.5 release development is under cover (0.5 is where a public demo comes in).

In the mean-while, proof of dual-sided collisions:
http://www.youtube.com/watch?v=JwL-nTODl2E&feature=user

Not only is it completely functional, but stuff can collide with itself. I don't think even Portal does that

Hm. Well, since you guys are programmers and all... I guess I'd like to share some more things

Mainly, Lua support. For example:

Code: Select all

-- ! -- test lua script -- ! --

d_addDefaultResourceDirs()
d_initAllResourceGroups()

d_setCameraPos(7, 7, 7)
d_setCameraLookAt(0, 0, 0)

light0 = d_createLight("light0")
d_setLightRadius(light0, 15)
d_setLightPos(light0, 0, 7, 0)
d_setLightColour(light0, 1, 1, 1, 1, 1, 1)
d_setLightDir(light0, 0, -1, 0)

--light1 = d_createLight("light1")
--d_setLightRadius(light1, 15)
--d_setLightPos(light1, 2, 7, 0)
--d_setLightColour(light1, 1, 1, 1, 1, 1, 1)
--d_setLightDir(light1, 0, -1, 0)

dd = d_getDataDir()
level = d_createScriptedObject(dd .. "/models/level1.lua")

for i = 1, 50, 1 do
    so = d_createScriptedObject(dd .. "/models/ball.lua", true)
    d_applyImpulse(so, 0, 15, 0)
end

d_enableShadows(true)

function lerp(a, b, n)
    return a + ((b - a) * n)
end

function tick(d)

    local x, y, z = 0, 0, 0

    if d_isKeyDown("W") then
        z = z + (-1 * d)
    end

    if d_isKeyDown("S") then
        z = z + (1 * d)
    end

    if d_isKeyDown("A") then
        x = x + (-1 * d)
    end

    if d_isKeyDown("D") then
        x = x + (1 * d)
    end

    d_moveCamera(x, y, z)
end

Then, in the game's console:

Code: Select all

dofile(d_getDataDir() .. "test_lua.lua")

And...


The engine did absolutely *nothing* before-hand. No resources, no shadows, no levels, nothing. Then, BAM! Some simplistic Lua and you have a full-on level testing going. With awesome shaders and real-time physics and everything.

This is how level creation is going to be done for the Disorder engine, via Lua.

Shot of the console and some real-time Lua:


BIG thanks to QuickGUI! Awesome GUI library for Ogre. Highly recommended.

[eugen]

very nice!

[JeDi]

This is looking cooler every update. The self-collisions look very intuitive (we can't really say "realistic" in this case ). I think this enables a lot of opportunities for original gameplay ideas.

Keep up the good work!

Greetz,
JeDi

[walaber]

this is the most impressive use of Newton Game Dynamics I think I've ever seen. amazing stuff!

I assume you are using a custom joint for the self-collision / cross portal collision, that is an amazing use of the joint system!

[nullsquared]

Heh. Yeah, custom joint. I only have junior high maths knowledge right now, so Julio helped me out a lot on the joint... most awesome physics engine author ever!