Pi3D

[toxibunny]

I'm really impressed with paddy's 3d bouncing ball demo, btw. seems pretty smooth, too. I bet that heightmap could be used for some really neat data visualisation type of stuff...

@JamesR: I didn't mean to be unfriendly back there - I just wanted to temper what I saw as a possibly annoying 'explain everything, pls!' request by asking what, exactly you wanted explaining. Obviously I was being too sensitive though, as Tom answered directly without getting irritated by us noobs

[Tom Swirly]

Linux editors seem to want a tab to = 8 spaces while on windows it was normally 4...

emacs at least defaults to 4 spaces - but even nicer, it looks at the first indentation when it reads a Python file and simply uses that, so you can edit in different projects with different conventions without changing any settings.

I generally use 2 because, well, that's what Guido uses and also because 2 spaces is perfectly clear while minimizing the width of my windows. I often have a zillion windows up so I hate it when I have to resize just one window so it's really wide to get it all in.

[Tom Swirly]

I've cloned the repo and making steady "clean up only" changes.

You can see the most current version here and a timeline of the changes I've made here.

Right now, my changes are simply to make the code as pythonic as possible using PEP 8 and to clean it up so I personally can understand it. I test somewhat with each checkin...

[paddyg]

Tom, this is great to see. I eventually got hold of a live mobile number for Tim Skillman and I've sent a text explaining how we are keen to move things along. (I spoke to the secretary of the church where he minsters and he is definitely alive and home from his extended holiday). I've started adding a collision testing method to the ..elevationMap.. and two things occur to me:
a) keeping track of which mods need to go in where is going to be quite tricky with the proliferation of versions!
b) I already added some stuff to the constructor of the ..elevationMap.. to generate 'proper' normals (as opposed to vertical normals on the original) and an option to produce 'smooth' or averaged normals. These bits of code could/should be moved up to pi3dCommon (as divided up) so they can be applied to all create_shape objects. Logically these methods would be used to generate the normals for all the standard shapes (though care no doubt needed not to turn things 'inside out')

[Tom Swirly]

I should at least add you as a collaborator to my codebase, if nothing else!

Need to get out and eat (I was up late) but will be back soon and onto the machine.

If you're adding functions that apply to "create_shape" objects (now renamed "Shape" objects because Python wants classes to start with a capital letter) you should add 'em to the shape subdirectory that now exists - perhaps even as methods to Shape...

[JamesR]

@Toxic I'm not worried.

It's just the time I have to spend on it. I've cleared my way through getting some flash based software running, Minko to be precise. I can leave that alone as it stands and go through things, but it's getting tricky with the wether to knw where I am to work things through.

Keep up the good work.
I'm just wondering if there's a simple tutorial you can do for us to try and write our own code. For example if I went through the pigame material, I'll find a few things in there like using mouse buttons, that it would be nice to know how to adapt and put in bits of python code from other sources.

It would be a stretch to explain how to write a loader for 3d file formats, but I'm sure there are some simple things.

[Tom Swirly]

Looking at the amount of cleaning I managed to do last night, I'm now thinking we should either fold that fork back into the main branch, or continue to work on the new fork.

My plan is to finish the "pure refactorings" today and then start to work on actually changing things. I already got a good suggestion from Paddy this a.m.

Regarding the thread issue that started this - my reading convinces me that unfortunately many of the calls do have to happen on the main thread.

It would be extremely nice if we could simply all the "texture" loading to occur on another thread. Basically, it's no big deal if the main thread has to hold the main loop, but it does affect the quality of your software if you have to load "assets" (i.e. images) from disk on the image redisplay thread - I can see my little demo "skip" each and every time it loads a new image from disk, it can be quite a jerk if the image is a large one.

[Tom Swirly]

I just added the three collaborators on the original branch as Administrators for the new fork!

Off to a well-earned breakfast now.

[paddyg]

As I mentioned before, I had arrived at the conclusion that image and model loading would be much nicer done with a background thread; so I think this would good to fix.

[Tom Swirly]

Unfortunately, I'm right now not getting a good feeling about the possibility of doing this without writing some C++.

I'm not seeing any reason yet in the Python why there would be any thread issues, so I'm now believing that the issue is that the C++ library itself can't be called from multiple Python threads - I see some evidence for this fact in discussions online.

One way to fix this might be to create a small C++ layer with simply some mutexes in it - but that is not a completely convincing strategy (how can you convince the third-party code in the lib*GL* libraries to call the code path with our mutexes?) and also really annoying (we'd have to maintain a separate C++ library).

Once we get to a certain level with this, I imagine we'll want to reach out to the maintainers of libGLESv2 and see what they can do for us - it's probably the best way to go, they should be happy to see a good Python wrapper for their code and want to help.

[paddyg]

Tom, even if we run the GL stuff in a different thread we would still need to do background image and object loading in (yet another) different thread along with casting to ctype arrays etc then pass the array to the GL thread. So the GL thread might as well be the main one. I haven't done any threading with python so I don't know what's allowed to pass between them.

Good news. I've just spent a while on the phone chatting to Tim Skillman. He's still keen to stay involved but has been very busy with a new job (in addition to his existing one). He commented:
- If we put together a prioritised list of functionality (as near to a full specification as possible) then he will try to start working his way through it. i.e. write Open GL ES 2 python interfaces to fit in with pi3d in its reconstructed form. He's already made a start on some of it.
- Ogles2 should be faster than Ogles1
- His brother is an expert in Ogles (works for for flight simulator company) and has bought himself a RPi so could well be persuaded to get involved.

Paddy
(off to find something out about python threading)

[Tom Swirly]

Oh, aces! Very good to know, because that's an area I don't know.

You're saying that the disk access part is already done in Python so we need merely to separate that from the actual loading part and then tell the main thread that it's done loading. We can do that!

[Tom Swirly]

Looking at a recent change, it's sort of textbook, so why not explain it?

I added comments to the commit to explain what was going on. Ask me if you have any questions!

[Tom Swirly]

I have finished the first stage of the refactoring of pi3d - that is, everything except the loaderEgg.

Take a look here and see what you think!

[paddyg]

slightly more streamlined pong with better shading and collision detection and normal calculation delegated to a method of ..elevationMap.. Also keeps track of whether bats are in the right place at either end and either bounces or throws in at centre
www.youtube.com/watch?v=oCF0dK-d0ZY
modified files here
https://github.com/paddywwoof/pi3d/commits/master

[paddyg]

I have finished the first stage of the refactoring of pi3d - that is, everything except the loaderEgg. Take a look here and see what you think!

Tom, looks much cleaner (though much swapping from file to file to figure out what does what (hence your earlier comment about having lots of windows open I suppose))
I figured out the 2d collisionballs so it doesn't need any trig. (This example is the basis of a really excellent demonstration of kinetic theory, the balls start out with random velocities but after a while the energy get distributed so they all have the Boltzman distribution, obviously the little balls are travelling much faster than the big ones)
Also I have added a method to ..elevationMap.. to check collisions and return a normal vector and modified the pong.py example.

At the moment I haven't thought through the best way to feed back my alterations into your branch. I could make a fork from dev and hold that in a different location on my RPi then work my way through the alterations I've made on the existing structure so they're reflected in my version. Apart from the things I've mentioned here I have made various tweaks as seen from my commits, some of which are really bug fixes. However I will only start to do that once you get to a clear point with your tidying.

I will look at your new code and think about how the texture and model loading could be split out from opengles methods. It doesn't look so difficult actually, the only thing in the model loading is loadtexture and the only thing in loadtexture are the three lines at the end which could be deferred until the first draw() of the object or put into an 'onloaded' routine called when the thread's finished.

[Tom Swirly]

Yes, it's unfortunate that there are so many files, but as I said before, it's very easy to glue them together again if needs be. This also makes for faster loading programs, because you only load what you need.

I think I've become used to "lots of little files" - my emacs session right now has over 1200 files open in it (from about four or five projects).

I am at a resting point in tidying - with the exception of the loaderEgg, I don't expect to make any other changes for a while. And I made you an administrator, so you could just check right in to that branch if you liked.

Regarding the "loading on a different thread" issue - my thinking is that we need to create a new, small class that handles the event loop, rather like the Display class of pygame or the Pi3dDisplay class from echomesh. At the start of each event loop, we'd see which files had actually loaded from disk and actually call those "three lines at the end" and then an "onloaded" method for the sprite.

I won't be working (much) on this for the next couple of days - so knock yourself out! I will, however, be reading this board...

[paddyg]

I'll have a go at putting rec/pi3d on my RPi and knocking loaderEgg into shape (you've set a high standard for coding that I will try and follow!) I will also add loaderObj and the various other things I think need to be in there.

I agree with the Display loop system. This is what panda3d does which is what I was looking at before arriving at pi3d.

[Tom Swirly]

It's likely I'll move Sprite and Pi3dDisplay from Echomesh to pi3d (which will also require Envelope, a generally useful class for "this sort of thing" with some tests).

Looks like we're going to be snowed in today, so perhaps I will get some time to do this!

[JamesR]

Well, I've waited for Midori to load for 1/2hr on the pi.. Anyone know the best OS or overclocking necessary to really use it? And still use pi3d.

Paddy, I edited the map for pong in mspaint and I succesfully got the raised bumps etc that i had created using the white and two greys. Simple. Next stage, creating a map, though the pi is painful at times.
Also is there any reason why the latest Pong update should crash?

So, I added the print screen shot line, but it fusses. Should I not add it like so?

Code: Select all

 #Press ESCAPE to terminate 
   159  +    k = mykeys.read() 
   160  +    if k==27: #Escape key 
   161  +    display.destroy() 
   162  +    mykeys.close() 
   163  +    break 
   164  +    else k==112 #key P
   165                     display.screenshot("PongScreenshot.jpg")
   166  +    display.swapBuffers() 

[paddyg]

James, Some pages take a while to load but I'm generally surprised how useable 'normal' software is on the RPi. I use GIMP for editing images on it (i.e. fractal) and it's really not too bad (haven't done anything bigger than 512 pixels)

Have you copied over the amended pi3d? There are quite a few mods in there that are needed (essentially the clashTest() method in ..elevationMap.. but I also put a check in calcHeight() to stop the occasional subscript error. Sorry about the number of non-changes highlighted, this was because I untabified the document using 8 characters which someone advised me was the best way to do it.

If you have the full pi3d then let me know what the error looks like and I will try and help

Your syntax looks wrong for python:
if x == y:
do(Something)
elif x == z:
do(otherThing)
else:
do(nothing)

[paddyg]

And I made you an administrator, so you could just check right in to that branch if you liked

Took the plunge and committed the changes to Ball.py I understand git is clever enough to keep track of all these potentially conflicting changes but still slightly worrying!

[Tom Swirly]

I've also found Midori on the RP to be barely usable - I assume it's simply lack of horsepower, not that there's anything wrong with Midori.

And... yaaaay! First other check-in!

[JamesR]

Yes, I was worried about the order of if, elif and else.
I've changed the code to:

Code: Select all

    k = mykeys.read
    if = k==122: #key P
            display.screenshot("PongScreenshot.jpg")
    #Press ESCAPE to terminate
    elif k==27: #key Esc
           display.destroy()
           mykeys.close()
           break

It returns an indentation error on the line
elif k==27: #key Esc
'Unident does not match any other indentation level' under the c of the Esc.
I thought the indentation was correct.
I d/l the pi master directory, and ran from there, so I think the files should be up to date on my pi. I didn't get an error from the original file, it just freezes fairly soon. Maybe a memory error rather than pi3d. ???

[BlackJack]

@JamesR: Please make sure the shown source belongs to the reported error. *That* code gives you a syntax error in the second line at the ``=`` after ``if``.

For the indentation: Use 4 spaces per indentation level. No tabs.