What are you working on? v67 - March 2017 - Developers

[QUOTE=phygon;52145769][IMG]http://i.imgur.com/wIByZY7.gif[/IMG][/QUOTE] I saw this a few weeks ago and my first instinct was A, but as people pointed out, it has to be B because of conservation of momentum. But as cartman300 says, the idea portals is very absurd and I felt like A might be what actually happens in-game in spite of the laws of physics. But I guess I was wrong.

[QUOTE=Dr Magnusson;52146993]While I instinctively feel like B makes sense, I think a good thought experiment is asking what happens if the piston doesn't go down all the way, but only covers the top 10% of the cube maybe. Does it still get launched?[/QUOTE] Yes, it's still B. Depends with what speed the piston moves tho.

I don't really see how B makes any sense. Where does the force come from that launches the cube? If anything it would face resistance when pushed through the portal because of the inert air on the other side.

[QUOTE=Clavus;52147822]I don't really see how B makes any sense. Where does the force come from that launches the cube? If anything it would face resistance when pushed through the portal because of the inert air on the other side.[/QUOTE] There is no force, but there also doesn't have to be one. The portals in this case here break both conservation of energy and conservation of momentum, which means an object's observed velocity can change without it experiencing acceleration. [editline]25th April 2017[/editline] [QUOTE=Fourier;52147636]Yes, it's still B. Depends with what speed the piston moves tho.[/QUOTE] The stability of the cube too, assuming it's not unbreakable. Any object passing through portals with mismatched acceleration would experience stress. The specifics depend on the thickness of the portal 'surface', but it's safe to say that the piston there suddenly stopping partway through could rip certain material apart.

I was making portals in UE4, it's a pain in the ass to ignore contact points that are inside the portal area but i got it to work pretty well. [vid]http://files.facepunch.com/Layla/2017/April/22/2017-04-22_02-28-13.mp4[/vid] I also figured out a way to easily render any component twice without duplicating the actor, only thing I can't do is custom clipping planes per object.

[QUOTE=Clavus;52147822]I don't really see how B makes any sense. Where does the force come from that launches the cube? If anything it would face resistance when pushed through the portal because of the inert air on the other side.[/QUOTE] Likewise, imagine just looking at the exit portal. If A was correct, you would see the cube start travelling out of the exit with a high velocity, but then immediately stop just as it fully leaves the portal. Relative to the exit portal, the cube had a high velocity but then had it suddenly cancelled out. Where does the force come from to immediately decelerate the cube? It seems like the least problematic way to think about it is not in terms of either the entry portal or exit portal's reference frames being exclusively correct, but to allow them to both have equal validity. So to resolve paradoxes like this you have to consider the portal to both be a spacial transformation and a transformation of velocity too. Just like how the relative position of the cube to the entrance portal affects the relative position of the cube to the exit portal as it passes through, the relative velocity is conserved in the same way. We already know this is true because if a falling object passes through a stationary portal on the floor, and leaves through a portal that's on a wall, the velocity is rotated to conserve relative velocity between the two portals. [editline]25th April 2017[/editline] Anyway to answer the question of where the force comes from to accelerate the cube through the portal, it would come from the platform underneath it. [editline]25th April 2017[/editline] I guess maybe a better way to think about it is that there's no way to distinguish between the cube initially being stationary with the portal moving towards it, vs the portal being stationary with the cube + platform moving towards it.

Additionally, one could assume the energy to move the cube comes not from the stationary platform (which is moving when viewed from the exit portal), but from the moving platform carrying the entry portal. When you slap a portal onto an object, it could encounter resistance in the same way that a magnet encounters resistance when you slap it onto a copper object (without physically touching said copper object). Which would also create some stress on the object itself as Tamschi mentioned. It's all fine when both of the portals are stationary, but when one moves it is kind of like bending the space itself. I imagine a portal on the surface of something would be very "heavy" and you'd really have to pump in a ton of energy to move it (the equivalent energy you would need to bend space itself into the same configuration) It's also weird that the gravity doesn't act trough the portals themselves.

[QUOTE=cartman300;52148505]It's also weird that the gravity doesn't act trough the portals themselves.[/QUOTE] That's a good point, you'd expect every field to attempt to maintain continuity so you'd get some crazy distortion of gravity around the portals if they are rotated relative to each other.

Real question, what happens if you push a surface with a portal through a portal? What happens when portals touch?

[QUOTE=layla;52148090]I was making portals in UE4, it's a pain in the ass to ignore contact points that are inside the portal area but i got it to work pretty well. [vid]http://files.facepunch.com/Layla/2017/April/22/2017-04-22_02-28-13.mp4[/vid] I also figured out a way to easily render any component twice without duplicating the actor, only thing I can't do is custom clipping planes per object.[/QUOTE] Can you not do custom clipping planes in UE4 itself, or is it just a limitation of how you're doing the portals? Also, great choice of music for the project. :v:

There's support for global clipping planes which is useful for clipping the portal rendering but i also need per object clipping to clip objects going into the portal. Well, it isn't absolutely needed but it's nice to have for portals that can be placed without a thick surface behind it It's only possible if I add support for it in the engine source but it's a fair amount of work, only other way is to have a base material that does the clipping

[QUOTE=F.X Clampazzo;52146513]Yeah, I've been using libnoise, and I found a guy who decided to migrate the library to x64 and I got it to compile properly after some tweaking just a moment ago so I'm now actually working on multi threading again, but now the program can run past the 32bit limits. I basically took heavily from the complex planet example and am slowly re-writing it, also I liked their colour choice so it stayed. Plus I needed a static output to compare my result to for accuracy, so I copied their noise module settings for now. I didn't see any reason to not use their settings since they were basically what I was going to do anyway lol, they just saved me the trouble of defining all the modules. Basically I've only got the elevation grid running on multi-threading right now because I've been busy migrating it to being x64. I can upload the last .ter I generated if you want, I'm not actually sure if it loads right since I don't have the program that opens them. Basically the largest limitation with the library is that it wants to generate everything on a divisibility of 180 since it has to reference a sphere map. So multithreading is really hard since your thread count has to be a factor of 180. Meaning basically everything but a 12 or 4 core processor are suffering some less than optimal performance since they can't run perfectly hardware concurrent. HOWEVER, every piece of information I can find shows that I will almost always still see a performance increase with multiple threads, unless I do something extreme like run 180 threads on a 4-core processor. Which I did. This 180 requirement also causes problems with map resolution and thread division because I can only have <180 threads due to what I call the 180 divisibility rule, and I have to split all work evenly per thread to generate the map correctly due to this a well. I tried it with more threads than 180 and it generated some funky shit when it doesn't divide out to a number that is fully in scope of a double, shit if it can't find work up to 180 it also makes bad images. I might return to that problem later, but for now obeying the rule of 180 is a fair solution. I haven't quite determined the parameters that occur with each element violating that rule, but it either results in a black bar on the top of the map or a loss of some detail as the output image is a zoomed in result from the full model since the resolution is out of scope. -code snip- Basically all I've done is migrate the end of the function that actually wrote the elevation map to its own function so I can use it to write chunks: -code snip- I pulled the curlon and curlat to their own in function variables because referencing in-function is faster iirc, but otherwise this is basically the same code that was used by the build() function to build the elevation map. I should probably pull xdelta and ydelta too but I haven't seen the need really, I honestly probably didn't need to pull the other 2. The way this works is essentially we only have to mutex anything that the stupid threads can use to steal returns. I might decide to mutex the slabptr call but it hasn't caused any problems yet even with 180 threads so idk, I'll see if it's relevant later. Basically the single largest sink of time is building the elevation grid and model, second to that is the output files but I think I can just push those into their own functions for each file and thread them, probably 1 thread per since honestly, writing files is peanuts in comparsion. Generating all the noise modules takes like, maybe a second at worst.[/QUOTE] Our super shitty DNS server at work ate my post I wrote so I'm going to be quick as I can on rewriting it since I have loads to do today: - When it comes to writing output files, you might find some slowdown like I did when it comes to normalizing the data. I wrote a simple little method to normalize stuff to fit neatly into the range of a datatype given as the template parameter for this method, which was kinda buggy at times. However, it'll also work well with magic numbers. I'm going to try to add the "magic number" version if I can find it. Regardless, it uses inline SSE instructions and even when having to load unaligned data and store unaligned data it still sped things up splendidly. [url]https://gist.github.com/fuchstraumer/2b4087d4df515af548c5edc99154aada[/url] - Have you thought of trying [URL="http://en.cppreference.com/w/cpp/thread/async"]std::async[/URL] to ease some of your threading woes? It comes up in Scott Meyers' Effective C++ book and it seemed like a great way to get threading without some of the issues that can come up with dealing with the lower-level constructs, especially when it comes to accommodating different hardware configurations - I got a large speed increase by implementing simplex noise into libnoise and rebuilding the library with that. I didn't make it x64 or anything though, but I did find that the simplex noise tended to be faster (I know Stefan Gustavson says it shouldn't be faster, but it seems to be) - If you're interested, I did get [I][URL="http://i.imgur.com/egDoLqz.png"]HUGE[/URL][/I] speed increases doing this stuff with a GPU ([URL="https://github.com/fuchstraumer/CUDA_Noise"]github repo link[/URL]). However, there's no good way to implement a turbulence module as far as I could figure out. That and I had to rely on CUDA support and all. The library needs tuning, cleanup, and documentation but after spending a whole academic quarter on it and writing 4000 lines of mostly painful code I've been leaving it alone (in a bad state, tbh). No turbulence module means I could never get the full module chain setup, and there's some trickiness with the memory abuse of the modules now. Unlike libnoise, the way my library works pretty much requires each module ot keep all of its data around until its explicitly destroyed. The Cache module is REALLY useful for this, though, as it will store values from the preceding module chain and then safely deallocate that module chain, saving RAM and VRAM. no documentation on my library as mentioned though, so I can't really recommend using it tbh. But its pretty much a CUDA clone of libnoise (only missing turbulence module), so you might find some speed tweaks or useful stuff in it I guess. Also I kinda have to use floats, since GPUs find double's to be pretty icky. Idk, this stuff tends to be a pretty complex problem so I'm just tossing things at you to see if anything sticks or is of aid.

I actually did try working with async, but I was having trouble being able to integrate it into libnoise for some reason. I was getting some major weird results with it that I just couldn't peg. I ended up finding it easier to work with a set amount of threads and having some quick logic to determine what will be most optimal for the process time. I could also technically use non rule fitting thread counts if I rendered the section that fit the rule first and then combined the remainder with just enough overlap to make it divisible and rendered that at the end. But I think I'll worry about that kind of fine tuning for optimisation after I get the rest of the bottlenecks figured out and tackle that right before/after I figure out what the shit is going on with my mountain generation. Implementing simplex noise instead is something I'll have to consider, but generating the noise for a 21600x10800 map takes about a second or two in my experience max. Moving to GPU processing would be nifty, but I've admittedly very, very little experience with gpu processing. Plus I'm not terribly fond of relying on specific brand's products, even though irrc CUDA now does run on AMD gpus? my doubles for lacunarity load fine from file, everything is within limits at generation, but yeah it's not looking right at the end. I get some seeds that generate well, and generating with their values in example planet actually produces the same result, so I'm thinking it's a flaw in their program depending on the seed, which since it's just an example program that makes perfect sense. I'll have to address that after I get my run-time down to something that isn't a few minutes per planet. But changing how seeds are handled isn't the worst thing ever, I hope that's all it is.

After a lot of stress I finally managed to fix the build of my Ludum Dare game. [url]https://ldjam.com/events/ludum-dare/38/$26646[/url] UFO GO HOME, a VR game for the Oculus Rift and Touch controllers. [t]http://i.imgur.com/Pf78vXE.jpg[/t][t]http://i.imgur.com/lN2zcWv.jpg[/t][t]http://i.imgur.com/YuHBbQ7.jpg[/t]

The way I think of portals is a hole in space, like a floating set of event horizons, anything outside of a portal is acted upon by the local forces, and no force exists or acts between the portals. Objects passing through a portal will not have their forces acted upon by the portals, only the forces on either side. If an object is sticking through the portal it is acted upon by both forces simultaneously. So in the example animation the cube is resting on the platform, only being pushed down by gravity prior to portal contact. The piston comes down with the blue portal on it, but when it encounters the cube the piston makes no contact and imparts no force. As the cube goes through the portal the forces on the orange side begin acting on the cube, and the cube starts appearing in the orange one, but it is still be held by gravity on the blue side. When a larger portion of the cube's mass is on the orange side, gravity would overcome the gravity on the blue side and it would tumble down the slope on the orange side. Here is a rough sketch of what i'm talking about: [img]http://i.imgur.com/zPDdeQN.png[/img] This is just how I think it would work, the nice thing about games is you can make them work however you want, you can defy physics or you can try and match physics with the real world. It's up to the person creating it.

Aha! I figured something weird out. The program asserts that mountain_amount must be < hills_amount but for literally all cases where that is actually true, it says it is not true and crashes the program. This is fucking weird, and I have no idea what is going on at a cursory glance. The program actually runs when hills_amount is greater than mountain amount. Maybe their documentation is bad or maybe I need to try removing the assert call that mountains needs to be < hills and see what it does? I'll find out later.

[QUOTE=Fantym420;52149263]The way I think of portals is a hole in space, like a floating set of event horizons, anything outside of a portal is acted upon by the local forces, and no force exists or acts between the portals. Objects passing through a portal will not have their forces acted upon by the portals, only the forces on either side. If an object is sticking through the portal it is acted upon by both forces simultaneously. So in the example animation the cube is resting on the platform, only being pushed down by gravity prior to portal contact. The piston comes down with the blue portal on it, but when it encounters the cube the piston makes no contact and imparts no force. As the cube goes through the portal the forces on the orange side begin acting on the cube, and the cube starts appearing in the orange one, but it is still be held by gravity on the blue side. When a larger portion of the cube's mass is on the orange side, gravity would overcome the gravity on the blue side and it would tumble down the slope on the orange side. Here is a rough sketch of what i'm talking about: [img]http://i.imgur.com/zPDdeQN.png[/img] This is just how I think it would work, the nice thing about games is you can make them work however you want, you can defy physics or you can try and match physics with the real world. It's up to the person creating it.[/QUOTE] Imagine the piston is coming down super fast, like 200 Mph. Watching the orange portal, the cube would emerge at 200 Mph as it's "pushed" out. But then what do you think would happen when the piston reaches the floor? Would the cube suddenly decelerate and just tumble out as if the piston was only going 1 Mph? Or would the momentum of the cube relative to the portal be maintained?

[QUOTE=Ziks;52149353]Imagine the piston is coming down super fast, like 200 Mph. Watching the orange portal, the cube would emerge at 200 Mph as it's "pushed" out. But then what do you think would happen when the piston reaches the floor? Would the cube suddenly decelerate and just tumble out as if the piston was only going 1 Mph? Or would the momentum of the cube relative to the portal be maintained?[/QUOTE] Honestly if you want to get really technical about this stuff it gets into things like general relativity and maintaining some fundamentals of spacetime, since the closest analogue I can think of is something like a traversable wormhole. I think, and its been ages since I've done any kind of math in this field (plus im not johnnymo1), but momentum here is the momentum of the portal, not of the object, so it shouldn't just go flying out. The cube doesn't suddenly gain momentum or energy from just passing through a portal that happens to be moving at high speeds. from there, the cube will either roll down the slope depicted or will stay fixed. this would just depend on the mass of the cube, the slope in question, and the coefficient of friction between the cube and the floor its on. This stuff really hurts my head though.

[QUOTE=Ziks;52149353]Imagine the piston is coming down super fast, like 200 Mph. Watching the orange portal, the cube would emerge at 200 Mph as it's "pushed" out. But then what do you think would happen when the piston reaches the floor? Would the cube suddenly decelerate and just tumble out as if the piston was only going 1 Mph? Or would the momentum of the cube relative to the portal be maintained?[/QUOTE] The cube won't never accelerate, the portal has no physical contact, it's just a hole in space/time, if the cube was off center and hit outside the portal at all the piston would the transfer force to cube at an offset position(point of contact), then it would come out the orange side spinning through the air. No forces are altered on any object passing through the portal, until part of it's on the other side, then the physics/gravity/other objects on the other side start acting on it. If you have a floor portal and a ceiling portal(aligned with each other) then gravity remains constant and accelerates the object to terminal velocity(over time), but if you have both portals on a floor the object seems to float between them because gravity is pushing down on half the cube, and "up"(still down though) on the other half, with equal force. So the speed of the piston/portal doesn't enter into the equation, only gravity since no contact is happening. Another way to think of it is this, cut a hole in a piece of paper, now drop it on something that fits through the hole without touching, that object is unaffected by the paper. A Portal is a hole just the same, but the exit is not just on the other side of itself, it's in a different spot entirely, but still behaves as a hole.

[QUOTE=paindoc;52149839]Honestly if you want to get really technical about this stuff it gets into things like general relativity and maintaining some fundamentals of spacetime, since the closest analogue I can think of is something like a traversable wormhole. I think, and its been ages since I've done any kind of math in this field (plus im not johnnymo1), but momentum here is the momentum of the portal, not of the object, so it shouldn't just go flying out. The cube doesn't suddenly gain momentum or energy from just passing through a portal that happens to be moving at high speeds. from there, the cube will either roll down the slope depicted or will stay fixed. this would just depend on the mass of the cube, the slope in question, and the coefficient of friction between the cube and the floor its on. This stuff really hurts my head though.[/QUOTE] Still, if this is a flat surface (or even a boundary gradient of sorts) that's traversed between mismatched portal velocities and the object [I]isn't[/I] 'accelerated' by the reference frame change, wouldn't that mean it would experience a lot of (in this case) compression? Even in that case, the (elastic) object would get launched because its atoms would accelerate to reverse that.

[QUOTE=Tamschi;52149955]Still, if this is a flat surface (or even a boundary gradient of sorts) that's traversed between mismatched portal velocities and the object [I]isn't[/I] 'accelerated' by the reference frame change, wouldn't that mean it would experience a lot of (in this case) compression? Even in that case, the (elastic) object would get launched because its atoms would accelerate to reverse that.[/QUOTE] afaik, there wouldn't be any compression effects. its not like a flat surface or anything, its some mindfuckingly confusing tear/hole in spacetime that works closest to the analogy of an ant traversing a sheet of paper by going through a hole punched in the paper. I mean, there are some theories of wormholes with "throats" of non-zero length but this is a nearly untrodden field of science based entirely on theories with very little to zero observation supporting it (not to demean it, but we're just hypothesizing and pontificating at this point). Portals have the most in common with Visser-solution wormholes though, so I'm pretty sure there's not a boundary gradient or throat to travel through or anything: something sticking through or going through a portal just [I]is[/I] at the destination or exit, with no traveling or distinct traversal present. I already have a wicked headache and I'm trying to figure out quaternion math at work, this isn't helping :v: [editline]edited[/editline] here's the visser-solution paper, if anyone can make sense of it or is interested. i can grok the general idea and outline of what he's saying, but most of it just SOARS over my head: [url]https://arxiv.org/pdf/0809.0907.pdf[/url] [editline]edited[/editline] hunh, some solutions for traversable wormholes reverse the chirality of everything and anything passing through the wormhole. Right-handed gloves become left-handed. Screws become lefty-tighty, righty-loosey. Text is mirrored. And so on. I just ... don't. and can't. surely there's a more informed physics guru in this thread?

[QUOTE=paindoc;52150008][...][/QUOTE] Thanks for the research pointers. I never got to that when studying so I don't know what to search for unfortunately.

[QUOTE=Tamschi;52150062]Thanks for the research pointers. I never got to that when studying so I don't know what to search for unfortunately.[/QUOTE] tbh this topic is making me want to start learning more of the formal maths too, since I plan on using traversable wormholes in the project I'm working on and I do like my hard sci-fi realities. This page was also exceptionally useful, and there's a link at the bottom to what seems to be a good textbook on this topic: [url]http://www.webfilesuci.org/WormholeFAQ.html[/url]

[QUOTE=paindoc;52150008][...] here's the visser-solution paper, if anyone can make sense of it or is interested. i can grok the general idea and outline of what he's saying, but most of it just SOARS over my head: [url]https://arxiv.org/pdf/0809.0907.pdf[/url] [...][/QUOTE] If I read this paper right, it only applies to completely unaccelerated/free-falling wormholes. [editline]edit[/editline] Or ones that experience equal acceleration? I'm not sure what g00 ≡ 1 means, and googling 'utrastatic' doesn't really help since it only gives me this paper and something about rope tension maxima. It also seems like it would cause 'launching' if one was moving since the spacetime across the boundary is flat and inertial systems aren't distinguishable. The main difference here seems to be that the wormhole in the paper connects disjoint universes, which solves the issue of closed time-like(?) curves that iirc occur otherwise (if you have more than one [editline]edit[/editline] or mess around with the wormholes like that last link describes). However, I don't think that would be an issue in a perfectly Euclidean space that just 'happens' to contain instant-travel portals :wink:

[QUOTE=paindoc;52150008]afaik, there wouldn't be any compression effects. its not like a flat surface or anything, its some mindfuckingly confusing tear/hole in spacetime that works closest to the analogy of an ant traversing a sheet of paper by going through a hole punched in the paper. I mean, there are some theories of wormholes with "throats" of non-zero length but this is a nearly untrodden field of science based entirely on theories with very little to zero observation supporting it (not to demean it, but we're just hypothesizing and pontificating at this point).[/QUOTE] Since the critical part of this thought experiment is that one of the portals is moving, you would have to adapt the ant-on-paper analogy to match it somehow. Also I think the elastic effect would happen even in case A, because if the atoms of the cube are stationary as they exit the portal, the next atoms to come through behind them would repel them away from the portal. The leading atoms would repel back in return, but since there's a stationary surface under the box I think that would lead to a net force facing outwards from the exit portal. [editline]25th April 2017[/editline] What about if the entrance portal was on Earth, and the exit was on Mars? Does the universe care about the velocity of the portals relative to each other?

[QUOTE=Ziks;52150308]Since the critical part of this thought experiment is that one of the portals is moving, you would have to adapt the ant-on-paper analogy to match it somehow. Also I think the elastic effect would happen even in case A, because if the atoms of the cube are stationary as they exit the portal, the next atoms to come through behind them would repel them away from the portal. The leading atoms would repel back in return, but since there's a stationary surface under the box I think that would lead to a net force facing outwards from the exit portal. [editline]25th April 2017[/editline] What about if the entrance portal was on Earth, and the exit was on Mars? Does the universe care about the velocity of the portals relative to each other?[/QUOTE] Right but, you ever seen that game show thing where they jump through hole in a moving wall? Same thing. If a portal is just a hole between two points, you're not going to have any forced imparted on you by going through it other than the forces of gravity on both ends respective to the bits of you on each end. You'd retain your previous momentum and such, which if it's 0, then it's 0 still, there's no way that you'd be magically propelled by the portal one portal, because the portal by definition has no physical surface to apply force to you, it's just some weird bend in space between two points, like digging a tunnel, no? If the ground moved you up into the portal you'd still move with the momentum the ground gave you, but if the portal moved to you there's no reason for you to shoot out of the other portal at that speed, because there was nothing to transfer momentum to you. So really, you've got this problem where it's your universe's definition of a portal that limits what actually happens. But in the idea that a portal is just a hole between 2 points, you'd see no acceleration caused just by entering a moving portal. Otherwise you'd instantly come to a stop if you were running and entered a portal that was moving in the opposite direction at the same speed, as if you had instead ran directly into a wall. Which makes zero sense.

[QUOTE=F.X Clampazzo;52150331]Right but, you ever seen that game show thing where they jump through hole in a moving wall? Or like, you ever played jump rope? If a portal is just a hole, you're not going to have any forced imparted on you by going through it other than the forces of gravity on both ends respective to the bits of you on each end. You'd retain your previous momentum and such, which if it's 0, then it's 0 still, there's no way that you'd be magically propelled by the portal one portal, because the portal by definition has no physical surface to apply force to you, it's just some weird bend in space between two points, like digging a tunnel, no? If the ground moved you up into the portal you'd still move with the momentum the ground gave you, but if the portal moved to you there's no reason for you to shoot out of the other portal at that speed, because there was nothing to transfer momentum to you. So really, you've got this problem where it's your universe's definition of a portal that limits what actually happens.[/QUOTE] Technically that's precisely the reason why it [I]would[/I] fling you out. 'Zero momentum' is very subjective even in our universe, and while games have a 'true' frame of reference for practical reasons, the physics are still usually invariant regarding its velocity (aside from air drag simplifications).

[QUOTE=Tamschi;52150344]Technically that's precisely the reason why it [I]would[/I] fling you out. 'Zero momentum' is very subjective even in our universe, and while games have a 'true' frame of reference for practical reasons, the physics are still usually invariant regarding its velocity (aside from air drag simplifications).[/QUOTE] I suppose, but if you put the portal on top of the piston throwing the portal down, since you had no momentum and just this portal moving around you, you wouldn't get flung into the air no? Same as if you had a hollow tube come down around you that didn't touch you in any way, it doesn't do anything. The gravity difference between the different faced portals would be an issue but I don't think it'd fling you at some insane speed like the example gave, maybe you'd end up being flopped out at speed, but I don't think the momentum would transfer to you since you're effectively not being pushed by any moving physical surface. The issue I have a real issue with I think is when you have it on two surfaces that face in the same direction. You'd end up with the same problem as the one that says "what happens if you were to jump down a hole that fell directly through the center of the earth?"

[QUOTE=F.X Clampazzo;52150350][...] The issue you'd have is when you have it on two surfaces that face in the same direction. You'd end up with the same problem as the one that says "what happens if you were to jump down a hole that fell directly through the center of the earth?"[/QUOTE] I don't think that's really related, since in that case you have a pretty conventional system. (The main issue is that you'd need a curved hole in all cases that aren't pole to pole.) Otherwise you're definitely right though, if the portals are fixed to each other and act like a 'too short' tunnel then there's no weirdness in terms of conservation of momentum (but conservation of energy is still broken).

[QUOTE=F.X Clampazzo;52150331]Right but, you ever seen that game show thing where they jump through hole in a moving wall? Or like, you ever played jump rope?[/QUOTE] I don't think that analogy is useful when one portal is moving relative to the other. I don't want to sound antagonistic, and I appreciate the effort, but it sounds like you read enough of what I'm saying to recognise that I disagree with your position, and posted your understanding of the scenario without reading the rest of my post. Analogies like Buster Keaton having a doorframe fall around him or playing jump rope aren't useful when one portal is moving relative to the other. The analogy doesn't tell us anything about this novel situation. Like so imagine the ant walking through a hole in a piece of paper analogy, except a sort of 1 dimensional case where it walks over the edge of a piece of paper to the other side. An intuitive adaptation to make it fit this scenario is if it's actually two pieces of paper, with one sliding across the other. When the ant walks across the edge to the other side, onto the second piece of paper, it suddenly finds itself moving relative to that piece of paper. Now that's either a good analogy for how the physics of a portal in a relativistic universe would work, or it's not. But if it isn't, I think it's fair to say that the analogy with just a single static piece of paper is at least as bad.