PS3 [Research] Modifying the Gaia Visualization (custom_render_plugin/earth.qrc)

pink1 said:
It happens lol you catch me messing up all the time :-p

You can get the cmd version here.
Click to expand...

This app is like the CubeMapGEN from AMD I linked in a previous post but on steroids lol. Much more options, I will take good look at it later on sometime, just had a quick look at it for now.

But from a first glance its a good app to gen Cube and Environment maps.
 
sandungas said:
Im not sure but... i think right now is not posible to identify that position of the starfield by looking at the images, there are too many ingredients in play
We are dealing with a rotate180º effect, or/and horizontal and vertical mirroring, and the fact we are not completly sure if the image is proyected into the opposite face (at least me im not sure about that, from time to time i think in it and my head is about to explode because it changes everything)
Click to expand...
Not possible to identify? we have screenshots and we know from those which one is displayed correctly.

I dont see how it being projected or placed makes much difference when we have screenshots? We know how it displays an image we give it, So if its mirror images projected from the back, or normal image projected from the front, its the same result which we can see by how our image displays.
 
pink1 said:
@DeViL303 Have you seen this free tool? It also comes in a cmd version he has some environment maps too.

cmftStudio_cover.jpg



https://github.com/dariomanesku/cmftStudio-bin/blob/master/cmftStudio_win64.zip?raw=true

https://github.com/dariomanesku/cmftStudio
Click to expand...
Oh, very nice find! :) I think this is just what we need.
 
DeViL303 said:
OK, I have no idea what I am doing... :)

This camera path
Code: 
time=0 eye 4.85042 -0.288142 5.20632 center 4.16031 -0.253807 4.48343 up 0.07519 0.99687 -0.0244323  fovy=500.00
time=10 eye 4.85042 -2.398142 5.20632 center 4.16031 -2.253807 4.48343 up 0.07519 0.99687 -0.0244323  fovy=50.00
time=20 eye 4.85042 -2.398142 5.20632 center 4.16031 -2.393807 4.48343 up 3.07519 3.99687 -0.0244323  fovy=500.00
time=30 eye 4.85042 -2.398142 5.20632 center 4.16031 -2.393807 4.48343 up 3.07519 3.99687 -0.0244323  fovy=50.00

Equals this motion:


We need AI... :D
Click to expand...
3D Pong in first person, lol




Edit:
Btw, the value named fovy is the "Field Of View in Y axis"
https://en.wikipedia.org/wiki/Field_of_view

It works pretty much as a zoom

The Y axis crosses the sphere at the "top" and "bottom" cube faces
 
Last edited:
pink1 said:
It happens lol you catch me messing up all the time :-p

You can get the cmd version here.
Click to expand...

Had a bit more play with this app and the cmd functions would be great for the app, you could add the gui to be launched as a cubemap as well so people can "preview" what it will look like but its not exactly for the average user if you know what I mean.

The only issue I have with this app is that it has Rendering issues with OpenGL backend on Windows if the User has a Radeon GPU. So the user must use DirectX9 or 11.
 
sandungas said:
3D Pong in first person, lol




Edit:
Btw, the value named fovy is the "Field Of View in Y axis"
https://en.wikipedia.org/wiki/Field_of_view

It works pretty much as a zoom

The Y axis crosses the spehre at the "top" and "bottom" cube faces
Click to expand...
Yeah, I got the zoom bit sorted, at least that was easy.. But I dont get why i need to have such random values to be able to see the earth.. I was hoping I could just zero them all and have the earth in the centre, but nothing, I need to start off with values like this or very close to it or I can see nothing.

time=0 eye 4.85042 -0.288142 5.20632 center 4.16031 -0.253807 4.48343 up 0.07519 0.99687 -0.0244323 fovy=xxxx

FOV can be anything of course, but the rest must be like that or close to it.

I guess its due to where earth is rendered in the 3D space. Not sure..maybe 0,0,0 refers the bottom corner of the cube or something. I will figure it out eventually with trial and error, but now its too slow to test mods..

For these mods I have patched the sprx to only use preset0 and have removed everything from the camera path for preset0 and started from scratch apart from the first line.

I need to be able to test multiple mods per minute really, for that I basically need to be able to drag and drop a camera.path onto the qrc or something and have it used as the path for preset0..

Man i wish we could run extracted QRC files from dev_hdd0/game/ABCD12345/ like the devs could...it would be so much easier.
 
Last edited:
DeViL303 said:
Not possible to identify? we have screenshots and we know from those which one is displayed correctly.

I dont see how it being projected or placed makes much difference when we have screenshots? We know how it displays an image we give it, So if its mirror images projected from the back, or normal image projected from the front, its the same result which we can see by how our image displays.
Click to expand...
I meant, the code is taking one of the .dds textures of the 24 total of the starfield and is generating the other 23 textures on runtime (by rotating mirorring or flipping the original)
..but by looking at the images is imposible to figure which one is the original

In other words... one of them is the real texture displayed in his real position (and we know that position is face_neg_z_ul.dds), but the other 23 are fake

-----------------
If we figure which one is each this could help a lot because it would allow to identify how are named the others for ground/clouds/textures
By now we know are named as 000_000, 000_001, 001_000, 001_001 but we dont have a solid proof of which one is each (from the 4 posibles "ul", "ur", "dl", "dr")

At this point i think we are not going to find a solid proof unless we find some code line where could appear mentioned literally... something like:
OPENGL_TEXTURIZE_CUBEFACE_0_POS_Z_UL = 000_001.jpg

If we find something like that... problem solved, and no doubt about it, but in the meantime is tricky to figure it
I was thinking a bit more about what we was talking yesterday, and im not so sure if what we said was right (there are only 2 ways though... is either what we said, or the inverse, lol... hard to explain)
 
Oh I get you now, yeah out all 24 we don't know which is "real".. but also even if we can enable them all which may not be possible. We are in a 3D space with full control over rotation and camera and textures, so even if there is an actual up/down, We should end up with enough control to make "up" be whichever way we want really when displaying it.

Also IF we enable them all then it will be no problem to identify them..So its a problem that will solve itself as soon as it becomes a problem. If we cant enable them all, we do not need to know where they would be placed.
 
Last edited:
I mentioned it because at this point im very interested to identify the face names (x,y,z and pos,neg)
And after that the "tile" names... the problem/magic with the tiles is his names follows different naming scheme for the sphere and for the starfield

In the sphere are named 000_000, 000_001, 001_000, 001_001
And in the starfield are named ul, ur, dl, dr

The handy thing is everything is following the same coordinate system... so we can use the textures on the sphere to identfy the textures of the starfield (and the other way around)

The goal of this idea is... if we find where is located face_neg_z_ul.dds in the starfield.... then we will know which tile is "ul" in the earth sphere (from the 4 posibles: 000_000, 000_001, 001_000, 001_001) :)







-----------------------
The only way that could work the idea i was mentioning the other day about adding 23 more .dds textures to the starfield is if the code already have a function like this:

if num_startfield_textures = 1 {
take the real texture, generate 23 fake textures with it, and apply them everywhere
}
else if num_startfield_textures = 24 {
do the real mapping
}

If the code have something like that it should work (and we know it existed internal versions of this in high quality, maybe there is some code like that before they did the quality downgrade)
 
Last edited:
Yeah, hopefully its like that, or maybe they just commented out some code or something but left everything else in place for re-enabling. The fact they were still considering a HDD release when they released the flash version might help us. Also we know from the PS3 XMB files which they worked on too, they do not like to remove stuff fully. :)

My theory is they leave everything in for maximum compatibility if they need to renable something, and also if want to be able to re-enable stuff themselves on their own machines... these devs have to be running their own CFW if they made the XMB. :) I know I would be.
 
Well, yes, what i said is the most optimistical approach, considering the code is actually ready to load and locate the 24 starfield textures in the real positions
Is not much probable that they did it with something as simple as what i said... but is a handy solution because doing it that way would allow them to use the same code for low-quality or high-quality starfields

The alternative is what you said, comenting or modifying a few code lines, but i agree with you, most probably there is no code removed (maybe some parts of it nuked, but not removed just incase they decided to step back at some point)

Also, as i said, the mapping of the textures around the sphere follows the same rules than the textures of the starfield, most probaly there are parts of code shared in between the sphere and the starfield texture mapping
Actually... it should be the same... except the fact the starfield creates the "fake" textures on runtime before are applyed
 
sandungas said:
and we know it existed internal versions of this in high quality
Click to expand...
I think as there are so many references to the dev_hdd0/game/ABCD12345 in all the related sprx files, and references to debug menus etc that we should try enable running that properly if we can...like everything else it is probably disabled very simply. The debug menu might not even be disabled at all and might even only need a button combo to enable or some flag file.

@esc0rtd3w @habib @Joonie If any of you guys have a little time... we could really do something cool with this if could enable the full quality and open this up. Q-Games put a lot of work into and is also like a "factory feature" that needs enabling in a way. :)

If any of you guys are interested I suspect it can be done in one of these SPRX files.
upload_2020-1-31_13-36-52.png


If we cant enable the proper HDD version it would be so amazing if we could remap the internal files of the QRC to the external files on hdd somehow.. Not sure if remapping/redirecting from inside a container to outside of it is possible...it probably is in RAM.

I actually wonder if I used the directory traversal trick to go up a level would it allow to get out of the QRC..probably not.. :)

On top of that we have a good idea of the dev_hdd0 versions folder/file layout from the visualizer app they made.

i have attached the 3 sprx files from 4.84 DEX if anyone else wants a look.
 

Attachments

DeViL303 said:
Yeah, I got the zoom bit sorted, at least that was easy.. But I dont get why i need to have such random values to be able to see the earth.. I was hoping I could just zero them all and have the earth in the centre, but nothing, I need to start off with values like this or very close to it or I can see nothing.

time=0 eye 4.85042 -0.288142 5.20632 center 4.16031 -0.253807 4.48343 up 0.07519 0.99687 -0.0244323 fovy=xxxx

FOV can be anything of course, but the rest must be like that or close to it.

I guess its due to where earth is rendered in the 3D space. Not sure..maybe 0,0,0 refers the bottom corner of the cube or something. I will figure it out eventually with trial and error, but now its too slow to test mods..

For these mods I have patched the sprx to only use preset0 and have removed everything from the camera path for preset0 and started from scratch apart from the first line.

I need to be able to test multiple mods per minute really, for that I basically need to be able to drag and drop a camera.path onto the qrc or something and have it used as the path for preset0..

Man i wish we could run extracted QRC files from dev_hdd0/game/ABCD12345/ like the devs could...it would be so much easier.
Click to expand...
0,0,0 should be located at the center of the sphere, and is usually named "world coordinates"
The center of the sphere and the center of the starfield cube should match with the world coordinates, so for them the "world coordinates" and his "local coordinates" are the same

The tricky thing is the camera have his own local coordinates, and a vector that indicates where is aiming
Probably the sphere and the starfield cube are static all the time, and everything is made moving the camera (the .PATH files i guess)



Btw... theoretically you can move the camera "out" of the starfield cube (to escape the universe and become god)
And i think we can calculate accurately the radius of the sphere btw (to try to go inside the earth sphere and become another kind of god), by now i think is equal to 1 tile of the starfield... in other words 1024 units/pixels (considering 1 pixel = 1 unit)
And the center of the starfield cubefaces are located at a distance of 2048 pixels/units from the "world coordinates" (because what i said in a previous post... the starfield cube seems to be exactly double the size of the earth sphere)
 
Last edited:
Got something :surprise:
@DeViL303 @pink1 take a look at it, is a cubemap generator that works in command line (confirmed)
http://wiki.alioth.net/index.php/Planettool
http://www.aegidian.org/bb/viewtopic.php?f=4&t=7843
https://github.com/OoliteProject/planettool
https://sourceforge.net/projects/oolite-linux.berlios/files/planettool-0.4.2-win32.zip/download

Planettool.exe (help menu)
C:\>planettool.exe --help

Planettool version 0.4.2
planettool -o <outType> <outFile> [-i <inType> <inFile>] [-g <generator>] [-S <s
ize>] [-F] [-J] [--sixteen-bit] [-L] [-R <ry> <rx> <rz>] [-H] [-V] [-Q]

--output, -o: Type and name of output file. Type must be one of: "latlong" (l), "cube" (c), "cubex" (x), "mercator" (m), "gall-peters" (g)
--input, -i: Type and name of input file. Type must be one of: "latlong" (l), "cube" (c), "cubex" (x)
--generate, -g: Type and name of generator. Type must be one of: "grid1" (g)
--size, -S: Size of output, in pixels. Interpretation depends on output type.
--fast, -F: Use faster, low-quality rendering.
--jitter, -J: Use jittering for slower, slightly noisy rendering which may look better in some cases.
--sixteen-bit: Save in sixteen bit per channel format (instead of eight-bit-per-channel format).
--flip, -L: Mirror the texture in 3D space (through the YZ plane) while rendering. This produces an "inside-out" texture.
--rotate, -R: Rotate the texture around the planet while rendering. The ry axis corresponds to the planet's axis of rotation.
--help, -H: Show this helpful help.
--version, -V: Show version number.
--quiet, -Q: Don't print progress information.

Planettool reads a texture map from an input file (in PNG format) or a generator function, and writes it to an output file (in PNG format). In so doing, it may change the projection and scale of the map, and may rotate it around the planet.
Planettool's design is geared for flexibility and quality. As a side effect, itis extremely slow. Don't be alarmed if it takes several minutes to do anything.



EXAMPLES:
planettool --output cube "cubemap.png" --input latlong "original.png" --size 512
Reads original.png, treated as a latitude-longitude map, and remaps it to a cube map with a side length of 512 pixels.

planettool -o c cubemap.png -i l original.png -S 512
Same as above, only less legible for extra geek cred.

planettool -o cube grid.png --generator grid1 --fast --rotate 30 0 0 --flip
Generate a grid, tilted 30 degrees and projected onto an inside-out cube map at low quality.



THE PROJECTION TYPES:
latlong: Equirectangular projection. In this format, the intervals between
pixels are constant steps of latitude and longitude. This is
conceptually simple, but inefficent; lots of pixels are crammed
together tightly near the poles.

cube: The surface is divided into six equal areas, which are projected
onto squares. These are then stacked vertically, in the following
order:
+x, -x, +y, -y, +z, -z.

cubex: The same projection as cube, but the squares are rearranged into a
more human-friendly layout (which can be printed and folded into a
cube if you're bored).

mercator: An angle-preserving map projection. The traditional projection for
sailors and people who can't be bothered to choose a more approp-
riate projection for whatever they're doing. Entirely unsuitable
for texturing, but possibly useful if you want a wall map.

gall-peters: A variant of the cylindric equal-area projection, in which the
proportions between different areas are preserved.


THE GENERATORS:
grid1: A grid with lines spaced ten degrees apart. Longitude lines are green in the northern hemisphere, blue in the south. Latitude lines are red in the western hemisphere, teal in the east.
Click to expand...

Im going to show you an example of what i did, basically we just need 2 commands
Download this image from NASA "blue marble" web ---> https://visibleearth.nasa.gov/images/74142/september-blue-marble-next-generation/74147l
world.200409.3x5400x2700.png



Planettool.exe (cube)
Convert the image with this command, it generates the cubemap with the cubefaces sticked to each others in a single vertical line
Code: 
planettool.exe --output cube "test_cube_1024.png" --input latlong "test.png" --rotate 0 45 0 --size 1024
ydoEnIS.jpg


Planettool.exe (cubex) (a.k.a. cube cross)
Convert the image with this command, it generates the cubemap as a cube cross
Code: 
planettool.exe --output cubex "test_cubex_1024.png" --input latlong "test.png" --rotate 0 45 0 --size 1024
slgNsER.jpg


Compare the results with this reference image using the official files, same stuff (and forget abotut he fact the "back" cube face is located at different position of the cubecross, in the practise it doesnt matters)

*The option "--rotate 0 45 0" (from the commands i suggested) is moving the meridian 0º to the left border of the "front" cube face (like the official images) ;)
in99NN6.jpg


The only annoyances i found are:
Only works with PNG :/
In the help info and in the official support thread is mentioned that is extremelly slow (on purpose to try to achieve the higest quality posible)... personally i cant tell if thats true about the quality... but i can confirm is slow :/



...anyway i guess you are going to like it @DeViL303 because with this you can automate all the image convertion process entirelly :victorious:
 
Last edited:
That sounds great. Nice find. I will work on updating the bat to handle flat maps and also inject the stars dds.

I just realised we can probably rebuild lines.qrc with high quality backgrounds that display BEHIND the wave. :) There will probably be cool potential there for mods.
 
Ohh and btw, look at this, planettool can convert in between the different proyection types, this is mercator
Doesnt have distortion along the equator, this is extremelly convenient for "free painting" on top of it :)
Code: 
C:\>planettool.exe --output mercator "test_mercator_1024.png" --input latlong "test.png" --rotate 0 45 0 --size 1024
uz7PWge.png
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top