Star Citizen on the Raspberry Pi?!

[paddyg]

@gavin, using blender on the RPi is as easy as 'sudo apt-get install blender' (v 2.78 so recent but not latest) and it has a very good ray tracing engine - cycles - 'built in'. However the number crunching requirement for ray tracing is beyond anything the RPi is capable of so a ten second render on a laptop takes minutes on the RPi. And you will need a four core later RPi, ideally the 3+. It doesn't run completely smoothly but it's fine to do modeling and texturing on medium size meshes (such as your steam-punk zeppelin).

You don't actually need the extended keyboard, everything is accessible using menus and the recent online docs spell out the menu route and the shortcut on each page... However you really need to spend a bit of time getting used to what the different bits of the blender screen are called i.e. Mode c.f. Panel c.f. Menu c.f. Properties Editor c.f. Area c.f. Tab etc before the docs make complete sense!

[Gavinmc42]

Thanks Paddy, seems like the Pi forums are out of date I only found old questions asking does it run?
Might have to fire up the new Raspbian release, going to need some more SDcards.
Need to check to see if mesa3D is better now in Raspbian.
Just killed my Gentoo64 OS, pushed it over the bleeding edge

Just compiling the build deps for Bforartists on Linux now.
Dependencies is why I don't like Linux and I'm now using baremetal which is silly, Ultibo is nothing like baremetal.
Had thought of rolling a simple diy 3d modeler in baremetal.
After watching only the build deps compile for hours I think it might be bit complex

Some of the features from bfora are coming in Blender 2.8, which I have downloaded but not installed yet.
Got so many versions now, hard to keep track.

Just want to do some simple obj/uv for testing importing into OpenGLES on Ultibo.
The mesa3D libs has a obj-viewer I can hack, it's got lots of stuff that can be hacked and learned from
Might use those samples first before learning Blender to make fancy stuff, practice chewing on a cow before the elephant so to speak.

Ok build deps done, now making bfora, few more hours? time for bed.
Will it magically make itself overnight ? Never can tell with big compiles.

If it works on Intel box, will bfora compile on Pi?
Apparently the UI on Blender is user configurable, is it modifiable enough to be as easy as bfora?
Try modding UI in 2.8? They really need UI options, easy, med, pro.
Lots to learn but at least I am on a signed motorway now not lost in the 3D jungle

Not sure if I should thank Tim for inspiring me, he makes it look easy.

[paddyg]

For better or for worse blender 2.8 requires minimum OpenGL 3.3 it won't run on my old thinkpad and I doubt it will work on RPi.

[Gavinmc42]

For better or for worse blender 2.8 requires minimum OpenGL 3.3 it won't run on my old thinkpad and I doubt it will work on RPi.

Thanks Paddy, I've got to read the small print.
I'm going to need much better hardware for that EEVEE real time raytracing/rendering stuff.
2.8 looks like it should make producing output even faster.

Hmm are they working on a Vulkan version?
Hmm maybe, put that thought on hold, review in a years time?
https://blenderartists.org/t/how-will-v ... /635912/14

There are many versions of Blender as all the old ones are available, a few may compile for Pi's.
Lots more features on the new version, might even have to upgrade my old PC with decent video card, motherboard, CPU, DDR.....

Anyway, sometime during the night, BforArtiist 1.0 which runs on Blender 2.79 compiled on my Linux box:D
Quick test and it seems to run fine, can make those Zep hulls in about 20secs now.
Still trying to figure it out in Blender, demented UI.
Hopefully I will slowly pick it up via osmosis while using bfora

There comes a time to stop sharpening the tools and start learning how to use them, I think I have reached that point, whew.
Been a steep learning curve the last few weeks. Well actually the last 6 years

Tim, check out the Blender 2.8 features, re rendering and lighting.
https://code.blender.org/2017/12/blende ... as-report/
Hmm 3D printing template, cool.
I need to start saving for new PC, perhaps Santa will be kind?
And by then bfora will support 2.8?

Thanks to the both of you for inspiring me and pointing me in a direction.

[Gavinmc42]

Some time in the night b4a compiled on my Linux Mint 18.3 box.
After replacing my dead mouse, new release Raspbian was up and running Blender 2.78.

Downloaded b4a source
https://www.bforartists.de/content/download#source
started at the ./blender/build_files/build_environment/install_deps.sh
https://wiki.blender.org/wiki/Building_ ... untu/CMake

Lots of numpy warnings.
Failed at the OpenColorIO no rule to make target.
Close but no cigar.

Time to try it on Gentoo64, which is not Debian based, will need to cross fingers and toes.

Anyway guys, try b4a on Windows and Linux if you hate Blenders UI.

[tipam]

Baked texture update ...


Finally UV unwrapped and created the baked texture (and light maps) for the Cargo bay ... here are the improved results including a quick video of how it runs ...

https://youtu.be/0tkeIJXGCxU

[paddyg]

Tim, that's really great. Not sure it's relevant but it did occur to me that one could use the full float range to pack two UV texture coordinates into each value i.e. split into frac() and floor() in GLSL. We used that in pi3d to get x, y, z, size, rotation, r, g, b, a, u, v, into the 8 float values of the standard array buffer for the point text system (and for the multiple texture elevationmap shader). Of course the resolution has to be slightly limited but that might not matter for shadows.

You mention in the video that there's full collision detection - is that just in z direction or are you checking x and y too now?

[tipam]

Tim, that's really great. Not sure it's relevant but it did occur to me that one could use the full float range to pack two UV texture coordinates into each value i.e. split into frac() and floor() in GLSL. We used that in pi3d to get x, y, z, size, rotation, r, g, b, a, u, v, into the 8 float values of the standard array buffer for the point text system (and for the multiple texture elevationmap shader). Of course the resolution has to be slightly limited but that might not matter for shadows.

Yes, it would be good to pack the array as you suggest - I need to take a look at the Pi3D shaders for inspiration! You've got some great shaders in there. My fragment shader is very simple; it did have fog and other experiments, but it's currently like this .....

Code: Select all

precision mediump float;       // Set the default precision to medium

uniform sampler2D u_Texture;   // texture
uniform float u_illum;		   // can be used to amplify the texture colour

uniform vec4 u_diffuseColour;
uniform vec4 u_ambientColour;
uniform vec4 u_specColour;
uniform float u_specPower;

varying vec3 v_LightPos;       // Light position
varying vec3 v_Position;       // Eye position.
varying vec3 v_Normal;         // Interpolated normal for this fragment.
varying vec2 v_UV;			   // Texture coordinate

void main()
{
	gl_FragColor = texture2D(u_Texture, v_UV) * u_diffuseColour;
	
	if (u_illum == 1.0) {
		vec3 lightNormal = normalize(v_LightPos - v_Position);
		
		float rDotV = max(0.0, dot(lightNormal, v_Normal));
		vec4 specular = u_specColour * pow(rDotV, u_specPower);
		
		gl_FragColor = vec4(gl_FragColor.rgb * max(dot(v_Normal, lightNormal), 0.1), gl_FragColor.a) + specular + u_ambientColour; 
	}
}

You mention in the video that there's full collision detection - is that just in z direction or are you checking x and y too now?

Yes, it does floor collision and forward vector collisions at foot and head positions - could still do with some improvement though

[paddyg]

That's pretty good, doing the collision detection on the mesh. Tricky doing the horizontal component and coping with things like railings or tables.

The shader is quite simple and will be fast but it gives a very good effect - it's a really sensible idea to use baked shadows. I found that, on the raspberry pi at any rate, if() blocks get executed whatever the result of the condition, just that the result gets discarded. Often it seemed faster to use the condition variable (u_illum, say in your code) in subsequent mix(), step() or smoothstep() calls. (Also, I suspect the compiler already does this for you, but you can sub your second dot() with rDotV.)

The pi3d shaders suffer a bit from an early design decision (on my part) to get the GPU to do the matrix inversion to put the light vector into the object frame of reference. Normally this is done by the CPU and passed as a uniform variable matrix. I thought that python would struggle to do the calculation (c.f. C or even java) however that was before I discovered the speed of numpy, maybe I ought to revisit it!

[tipam]

That's pretty good, doing the collision detection on the mesh. Tricky doing the horizontal component and coping with things like railings or tables.

The shader is quite simple and will be fast but it gives a very good effect - it's a really sensible idea to use baked shadows. I found that, on the raspberry pi at any rate, if() blocks get executed whatever the result of the condition, just that the result gets discarded. Often it seemed faster to use the condition variable (u_illum, say in your code) in subsequent mix(), step() or smoothstep() calls. (Also, I suspect the compiler already does this for you, but you can sub your second dot() with rDotV.)

The pi3d shaders suffer a bit from an early design decision (on my part) to get the GPU to do the matrix inversion to put the light vector into the object frame of reference. Normally this is done by the CPU and passed as a uniform variable matrix. I thought that python would struggle to do the calculation (c.f. C or even java) however that was before I discovered the speed of numpy, maybe I ought to revisit it!

Thanks! That's really useful info - I didn't know the if() blocks get executed anyway!! .. also thanks for spotting rDotV ... I should have seen that

[Gavinmc42]

I am waiting for the other shoe to drop and you say this is done on a i7 with a GTX1080 running Raspbian Desktop.

Full screen, wow , wow, wow. (insert many Yorkshire understatements here)
Love the radar display.
This stuff just has to go into the Pi Mag, with tutorials?

Maybe too advanced for Primary but I can see Secondary Schools teaching it.
Just getting a 3D modeler working on Pi's will go a long way, should be a separate post.
Do I really have to learn Blender

How much better can it get on Pi's?
How close are you to it's limits?
How much further can the code be optimized for the VC4?

Wonder what the implication of this are for VC5 settop boxes?
Settop Boxes playing games? Whoops they do that now.

I really need to find more time to try this stuff.

[Gavinmc42]

Anyone a build deps expert?
Need to fix the image icons on the buttons
And yes it does work, you just need to guess icons.

You know there was a Blender pocket edition using OpenGLES, long time ago.

[Gavinmc42]

No idea how to do Raspbian screenshots.
Bforartists compiles and works in Raspbian
How well it works I have no idea yet.

Ok pretty slow, - sudo raspi-config enable OpenGL, reboot.
Whoops I think I just broke Raspbian, not rebooting.

So far Gentoo64 is faster but has icon button image issues.
Raspbain is slow and breaks if you enable OpenGL.

[tipam]

(Yet) another update!

OK - I stripped the fragment shader down by removing the light calcs and the 'if' statement (Thanks Paddy!) ... I also implemented atmospheric fog calculated in the vertex shader and passed the resultant fog colour to the frag shader.

As a result the frag shader is now just ONE LINE long in the main{} and works a treat! Here it is ...

Code: Select all

precision mediump float;       		// Set the default precision to medium

uniform sampler2D u_Texture;   	// texture
varying vec2 v_UV;				// Texture UV coordinate
varying vec4 v_diffuseColour;		// Diffuse colour
varying vec4 v_fogColour;			// Fog colour

void main()
{
	gl_FragColor = texture2D(u_Texture, v_UV) * v_diffuseColour + v_fogColour;
}

As you can guess, the speed improvement and rendering quality is much better (40-50 fps, 1920x1080)

Here's another quick update on the results ... https://youtu.be/0tkeIJXGCxU






Here's what it used to look like ...

[tipam]

DOWNLOAD LINK FOR DEMO

OK, not sure if this is going to work BUT here's a downloadable 'executable' of what I have so far
(I'm not quite ready to submit all the code yet - still needs tidying up quite a bit!!)

DOWNLOAD HERE http://www.skillmanmedia.com/images/Car ... emoRPi.zip

After setup (below), do the following;
1) Uncompress and copy files to desktop
2) Change permissions for 'ShipDemo' so 'Anyone' can execute it
3) run the 'ShipDemo' file from a terminal

This has been tried on a Raspberry Pi Zero running around the same speed at 40-50 fps, 1920x1080 resolution (seriously advise heatsink )

Notes:.
Use mouse and AWSD keys to navigate cargo bay.
Click right mouse button to exit once up and running.
Fullscreen demo works with direct connection to HDMI screen supporting 1920x1080 resolution.

Code: Select all

Setup:

1. Enable HW GL driver

$sudo raspi-config
  > Select Advanced-Settings>GL Driver>Full KMS GL Driver
  > Partition 128Mb (Pi3) / 64Mb (PiZero) for GPU
  > Restart


2. Install latest SDL2 2.0.8

See 
	https://choccyhobnob.com/raspberry-pi/sdl2-2-0-8-on-raspberry-pi/

and follow choccyhobnob's instructions 

[paddyg]

Tim, it runs great. I get 45 to 50 fps on this 3+ but the CPU is only clocking 7 to 12%, On a 2B it's nearly as fast at 43 fps and occasionally gets up to 18% CPU. I had previously attempted to get SDL hardware accelerated following instructions based on choccyhobnob but specified 2.0.5 and then when I tried to run it without installing any of the libraries it complained that it couldn't find SLD_image but when I tried to make that it wouldn't compile because SDL_LoadFile_RW didn't exist. Apparently this was only added in SDL 2.0.7 so I had to sudo make uninstall the old version then follow the instructions for 2.0.8 and everything was fine.

SDL still seems to use the new drivers which require X11, not sure how to get it to use /opt/vc/lib/libbrcmGLESv2.so directly

Paddy

PS I might enable the ESC key to quit and SetRelativeMouseMode(true) then use mouse velocity to increment rotation and tilt (or make ESC toggle relative mode)

[tipam]

Tim, it runs great. I get 45 to 50 fps on this 3+ but the CPU is only clocking 7 to 12%, On a 2B it's nearly as fast at 43 fps and occasionally gets up to 18% CPU. I had previously attempted to get SDL hardware accelerated following instructions based on choccyhobnob but specified 2.0.5 and then when I tried to run it without installing any of the libraries it complained that it couldn't find SLD_image but when I tried to make that it wouldn't compile because SDL_LoadFile_RW didn't exist. Apparently this was only added in SDL 2.0.7 so I had to sudo make uninstall the old version then follow the instructions for 2.0.8 and everything was fine.

SDL still seems to use the new drivers which require X11, not sure how to get it to use /opt/vc/lib/libbrcmGLESv2.so directly

Paddy

PS I might enable the ESC key to quit and SetRelativeMouseMode(true) then use mouse velocity to increment rotation and tilt (or make ESC toggle relative mode)

Fantastic! I'll upload another version with ESC key exit and an options file so you can change resolution / window options etc..

I'll let you know in the next post

[tipam]

Updated the Cargo Spaceship demo to include an options.txt file so the following parameters can be changed;

• screen: width, height, perspective value

• fullscreen: true or false

• fly: true or false

• startpos: x,y,z

• nearzfarz: nearZ, farZ

Also added Escape key to exit.

Same link as above. Enjoy!

Ps. please let me know if anyone is having problems running the demo? Thanks.

[paddyg]

Tim I can report that the updated version runs fine (and changing the options works as expected). As an experiment I tried loading your model into rust_pi3d to get a direct comparison. I just used the uv_flat shader as is which might be a little more complicated but not much. Although it runs OK it's not as fast your c++ version, but it seems to do proportionately less CPU work. i.e. the difference in speed seems to be due to the OpenGL side of things.

In my code I've just followed the pi3d system which basically followed some examples done by Peter de Rivaz and Jon Macey and the main bottleneck seemed like it would always be the python. However I think perhaps there might be inefficiencies in how the OpenGL is implemented. In your c++ code do you specify ES subset. Is your code on a repository anywhere?

Anyway, it's a fantastic model and here is a video of rust running it on laptop and RPi https://www.youtube.com/watch?v=hk8LgOqYEAA

[tipam]

Tim I can report that the updated version runs fine (and changing the options works as expected). As an experiment I tried loading your model into rust_pi3d to get a direct comparison. I just used the uv_flat shader as is which might be a little more complicated but not much. Although it runs OK it's not as fast your c++ version, but it seems to do proportionately less CPU work. i.e. the difference in speed seems to be due to the OpenGL side of things.

In my code I've just followed the pi3d system which basically followed some examples done by Peter de Rivaz and Jon Macey and the main bottleneck seemed like it would always be the python. However I think perhaps there might be inefficiencies in how the OpenGL is implemented. In your c++ code do you specify ES subset. Is your code on a repository anywhere?

Anyway, it's a fantastic model and here is a video of rust running it on laptop and RPi https://www.youtube.com/watch?v=hk8LgOqYEAA

Paddy, thanks for trying it out and doing the useful comparisons - clocking almost 500fps on your laptop!!

I haven't uploaded the code to a repo yet although I must do that soon so you can take a look - I haven't done a lot of shader work so I'm sure you will find inefficiencies ... it would be great to max out the Pi and see how much we can push it!!

I'll work on the other sections of the ship next and try seamlessly swapping between geometries. Using this technique it should be possible to generate some big games on an RPi and take advantage of the fast load times between scenes.

[paddyg]

Great, looking forward. The laptop speed increased dramatically when I installed the latest drivers, This is my son's old laptop but it has a GeForce GT 525M/PCIe/SSE2 card. Previously it always ran at 60fps but now it will run at almost any speed! With the demo I videod I had set the fps at something higher than I knew the RPi could manage: 500fps. If I set it to 1000fps then it varies depending what geometry I'm looking at (so probably limited by vertex operations) but slowest is about 600fps, highest 990 when just looking at the sky box!

On the RPi, when I reduce the window size to 800x600 or smaller, with both your c++ and my rust demos the fps maxes out at 60fps, however I installed the GeeXLab demos (as Gavin suggested) and some of those run much faster than 60fps so it's obviously possible. Hmm.

[tipam]

... it just goes to show how little power is required to produce some amazing stuff at such low cost!

[Gavinmc42]

... it just goes to show how little power is required to produce some amazing stuff at such low cost!

Yep, and the possibility of doing it all including the modeling and textures on a Pi is really interesting to me.
Gentoo64 comes with Gimp too, just need to figure out those missing icon images in b4a.

Apart from some annoying screen flicker the cargoship model can spin and move at a quite reasonable speed.
An OpenGL Render Image was just a blink.
Because Blender is a OpenGL based UI, CPU usage is very low and not much memory (10.6%)is used.
I need to know much more about b4a and Blender to use them.
Been watching b4a/Blender tutorial youtubes, so many of them out three .

I think for Ultibo I can eliminate the need for SDL.
Just need to get my head around obj to vertex conversions.
This also tends to indicate it should be possible to do it in Raspbian/Gentoo without X11 too.

Was told about this game engine that has worked on a Pi2
https://www.cafu.de/news/

The Cargoshipdemo is only 336KB
I can see some advantage of keeping the models in obj/png files.
Some scripting language and changing the obj/png and you have a different game/display etc.

[tipam]

Kendal Castle

Just tried a BIG model I did several years ago when I was in Kendal ... a reconstruction of Kendal Castle! (loads of rooms to explore!!)

I had a few issues converting it and found a bug in my OBJ loader (fixed) ... model weighs in at 75K triangles (1.8M floats of info) so I expected it to really chug ... instead it ran at a respectable 26-30 fps!

Still needs some tidying of baked textures but here's some pics ...

[Gavinmc42]

You just happen to have a Castle obj?
How long it it take you to do?

I don't really understand the tile engine in the VC4, but there maybe ways to use that to increase fps.
No idea how optimized the OpenGL/ES drivers are, generic or VC4?
GPU Drivers get improved all the time as people tweak them.

Are there any tools to check the VC4 % usage?
More baking, less triangles?

Recently saw some VR stuff, people sit in swivel chairs and they can see the room as it was in different periods over the centuries.

Wonder if a Pi could be set up to serve 3D models to peoples smart phones.
Weatherproof box at the old Roman Villa ruins?
This Pi stuff is now at a stage school kids could do this?
Pi's in archeology? Pi TimeTeam?

Drones now do 3D mapping, 10 mins flying, few hours cpu = Castle mk2?
That staircase pic reminds me of Return to Castle Wolfenstein