UE2 - UT2kX Modding UT2004 for virtual sensor

  • Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.

peterw

New Member
Oct 20, 2011
2
0
0
I'm working with an open source simulator, and i'm asking if it's possible to get depth buffer information from UT2004 for a 3D sensor implementation.

Currently, only lowering the resolution also decreases the time, but i don't want to go this way.
For a resolution of 640x480 the time to get a full scan is about 60 s.
At 320x240, the time is about 15s.

The question is if via modding the depth buffer can be returned and used as the sensor output and if possible how one could implement this.

Thanks.
 

Wormbo

Administrator
Staff member
Jun 4, 2001
5,913
36
48
Germany
www.koehler-homepage.de
I don't think you can access that data via UnrealScript. The closest thing would be tracing forward from the camera location, but that would not only be slow, it would also only give you the collision shape of the scene, not the visible one.

Maybe a third-party tool can read out the depth buffer while UT2004 is running. Communication with outside programs can be done though UdpLink or TcpLink.
The only other option would be native code, but as a modder you won't get access to that.
 

peterw

New Member
Oct 20, 2011
2
0
0
Is it possible to optimize rotation calculations

I don't know if a third party application can read depths from ut2004.
The only alternative that i see to get these depths other than in UScript is through intercepting and modifying the renderer (opengl or directx) calls and write to memory the depths.

Seems that the sensor i intend to use is quite simulation intensive.
I observed that at the desired resolutions FPS lowers dramatically, which means that the simulation phase (unrealscript code for sensor) takes some serious cpu or gpu processing.
It's a 3D sensor (scans in the horizontal and vertical) which depth for every point is returned from a Trace function call.

I've use the script profiler for ut2004 and the major resource hungry functions were those related to this sensor. Other much more simpler and different sensors don't even come close to the numbers presented by the 3d sensor in the profiler.
In the version tested in which ut2004 stayed stable(in fps and the vehicle not having strange behaviour like moving or flying when no input interaction exists), the main function of this sensor takes above 50% resources in function calls, and about 30 miliseconds for each call. These statistics were obtained for a 1200 point full scan.
Unstabilising versions of the sensor (higher resolutions) scored above 80%.
Ideally, i would want to use at least a 320x240 resolution for the scan.

So, now i've looked at the developed code and as a last attempt i'm trying to see if it can be optimized even in a minimal way that allows a greater resolution than the current one.

The sensor in itself is comprised of a double for loop that iterates with the vertical and horizontal angle steps(resolution) that add to the defined start angles.
In these loops is where the main work is done. The 2 angles(start angles+step angles) are passed into a rotator that is then passed to a function that i assume that rotates the sensor in the correct direction.
Then the Trace function call is executed and the depth returned.

In short, the main function calls 3 other functions: the rotation, the trace, and the float to string (to pass the depth values to a client application through tcp).

Of these functions, the one that has grounds to improve in optimization effort is the one that does rotations.

The code for this function exists at the vector math section of the unreal wiki:.

I would like if someone could please explain what this function is doing.
Or if there's a more efficient/optimal alternative.

Thank you!