FTC's Scribbles

Hey all,

so I think it’s time for one of these again. Technically is no wip and it is no released project either, but a collection of some one-nighters or other things I did just cause. The Work in Progress section seemed to be the right place for UDK, so I’ll post this here as well.

My latest one is a bunch of post process effects:

Previous scribbles:

  1. My first time C++, controlling a cloak material instance:
  2. Testing out Behavior Trees:
  3. Sliced volume renderer:
  4. Slate test with materials:

That’s all for now, I will post more whenever I did something new. Currently fiddling around with portals, but so far I am not sure if it will turn out good enough to show :wink:


Man, you rock! I love to watch your videos! You show so many good stuff.

Thank you :slight_smile:

The portal stuff turned out better than expected after all:


Amazing as aways. Great job!

Hi FTC. Can you show us how made is it?

Bookmarked! Loving the different viewing types!

Would be great to see how you did some of this stuff :slight_smile:

Relly cool!

@Daren / TheJamsh
If I find the time, I got so much stuff at the moment that I am glad if I can get these tests to a presentable state :wink:


Happy Halloween!
Spooky Scary Default Skeleton :slight_smile:

Fantastic work FTC!! Makes me want to go back and reply my Splinter cell games. I really like the Invisible Man project as well. Keep up the great work!

Portal doors are awesome! Mine still suffers from one-frame lag in the capture unfortunately.

Many thanks! :slight_smile:

@Tom Looman:
My first prototype was using blueprints and I had the same issue, then I switched to C++ and set the tick group of the actor that controls the capture and view calculations to TG_PostPhysics, which solved it.


Cool, thanks! Tried that in BP (by adding Tick dependencies, since TickGroup assignment isn’t available) but didn’t work. I’ll try C++ when I get back to this.

Can’t wait for some updates on those portals. Most eager to use something like them.

I tried this quite a while back in UDK, but it turned out impossible because of a native engine stall whenever the vehicle was upside down. UE4 does not seem to have this limitation anymore so I successfully implemented driving on the ceiling, albeit in a quite hacked manner.

Disabling gravity makes the tires lose all grip ( ) so I add force to counter act that and then additional force to achieve a custom gravity direction.

The biggest hurdle however was to get the tire’s suspension to actually go in two directions. I do traces to check for ground contact and then rotate the vehicle actor accordingly. Additionally I use the Anim Blueprint to rotate the vehicles root bone 180 degrees, which makes the flip almost unnoticeable.

As always the Lego brick models are based on exports from

I can’t promise that there will be any updates, this thread is mostly for proof of concepts and one-nighters.


Some while ago i presented som very WIP Portaleffect. It suffered from several problems, i didn’t manage to fix for the UE4 implementation, yet.

For capturing i use one of the Capture2D components. Based on Actors Camera position and angle, the Capture2D component updates itself. However, the projected picture always seems to lag a bit behind, when rotating the Player’s camera. I think this is caused by the fact, that the Capturecomponent updates it’s rotation/position before the PlayerActor Ticket. Currently thinking about updating the Capturecomponent from within the Players Tick-Function to avoid this. Rendering is done at the end and not during tick for all targets anyway, right?

How do you react to screenresolutionchanges? For example when switching between Window/Fullscreen. Everytime the resolution changes, the RenderTarget for the CaptureComponent needs to resize itself to the new Resolution. Not yet figured out how to do this.

Hope you can give me some tips on how to archieve this in UE4


I am pretty much using the same technique:

That said I have no system in place for resolution changes, the portal image just distorts and since I am not really working on any project that uses this I haven’t given it much thought. I would however suggest using render textures created by the capture actor from C++ at runtime, rather than assets in the content browser. That way you can destroy the textures and replace them with a new one having the correct resolution at runtime as well.


Didn’t know about the existense of Tickgroups!
Thank you very much

That portal is pretty awesome. How is it performance wide? Could it be made much bigger, ie 10,000 UU long by 5,000 UU high?