A simple 3D animation created with Maxima.

One of the things which I find myself doing quite often is, to be undertaking some sort of task on the computer(s), that I know is possible, but, not knowing in advance what the correct syntax and semantics are, to perform this task. This tends to take me on some sort of search on the Web, and I’ll find that other people have undertaken similar tasks, but not, a task with the same combination of parameters, as my task.

Thus, Web pages can be found according to which 2D animations have been created using a free, open-source Computer Algebra System named “Maxima”. Other Web pages may explain how to create various types of (static) 3D plots. But there may just be lacking examples out there, on how to create the 3D plot, but to animate it.

Using Maxima, there may be more than one way, such as, to keep refreshing the 3D plot over a time interval. But I find that such solutions tend to be second-rate, because of their use of busy-wait loops, as well as the possibility that they may otherwise be wasteful of computing power. I think that the best way, perhaps, to get Maxima to generate an animated 3D plot, could be, in the form of an animated GIF File (of course, as long as there isn’t an excess of frames to this animation).

Thus, the recipe that seems to work is as such:

 


load(draw)$

scenes: []$

for i thru 20 do (
    scenes: append(scenes,
            [gr3d(explicit(sin(%pi*(x+(i/10)))*cos(%pi*y),
                x, -1, 1, y, -1, 1))]
        )
)$

draw(
    delay = 10,
    file_name = "wavy",
    terminal = 'animated_gif,
    scenes
)$

 

The script outputs a file named ‘wavy.gif’ in the same folder, as whatever folder it was originally stored in. In some cases, the GIF File may appear in the user’s home directory, or even, in a temporary directory that’s difficult to find, unless the user also gives a full-path name for the file.

And, this is the GIF File that results:

wavy

 

Caution:

My most recent posting had to do, with a version of Maxima that had been ported to Android. The example above will not work with that version of Maxima. In fact, I can really only be sure that this feature works under Linux, which is the O/S that Maxima was mainly designed to run on. Any directives to ‘plot()’ or ‘draw()’ open a separate GNU-Plot window, which behaves in the predictable way under Linux, including the user’s ability to rotate the 3D plots interactively. AFAIK, commands to change to a non-default ‘terminal’ (for drawing and/or plotting) will fail on other platforms.

But, There is also a Windows or Mac alternative to using this platform, which mainly presents itself in the application ‘wxMaxima’. Here, the functions ‘wxdraw2d()’ and ‘wxdraw3d()’ replace those that open a separate window, and both embed their results in the wxMaxima worksheet. In order to make this more versatile, wxMaxima also offers the functions ‘with_slider_draw()’, ‘with_slider_draw3d()’, ‘wxanimate_draw()’, and ‘wxanimate_draw3d()’.

Potential ‘wxMaxima’ users will find the documentation for how to script that Here.

(Updated 7/06/2020, 15h35… )

Continue reading A simple 3D animation created with Maxima.

A bit of my personal history, experimenting in 3D game design.

I was wide-eyed and curious. And much before the year 2000, I only owned Windows-based computers, purchased most of my software for money, and also purchased a license of 3D Game Studio, some version of which is still being sold today. The version that I purchased well before 2000 was using the ‘A4′ game engine, where all the 3DGS versions have a game engine specified by the latter ‘A’ and a number.

That version of 3DGS was based on DirectX 7 because Microsoft owns and uses DirectX, and DirectX 7 still had as one of its capabilities to switch back into software-mode, even though it was perhaps one of the earliest APIs that offered hardware-rendering, provided that is, that the host machine had a graphics card capable of hardware-rendering.

I created a simplistic game using that engine, which had no real title, but which I simply referred to as my ‘Defeat The Guard Game’. And in so doing I learned a lot.

The API which is referred to as OpenGL, offers what DirectX versions offer. But because Microsoft has the primary say in how the graphics hardware is to be designed, OpenGL versions are frequently just catching up to what the latest DirectX versions have to offer. There is a loose correspondence in version numbers.

Shortly after the year 2000, I upgraded to a 3D Game Studio version with their ‘A6′ game engine. This was a game engine based on DirectX 9.0c, which was also standard with Windows XP, which no longer offered any possibility of software rendering, but which gave the customers of this software product their first opportunity to program shaders. And because I was playing with the ‘A6′ game engine for a long time, in addition owning a PC that ran Windows XP for a long time, the capabilities of DirectX 9.0c became etched in my mind. However, as fate would have it, I never actually created anything significant with this game engine version – only snippets of code designed to test various capabilities.

Continue reading A bit of my personal history, experimenting in 3D game design.

A disadvantage in running Linux, on a multi-core CPU that’s threaded.

One of the facts about modern computing is, that the hardware could include a multi-core CPU, with a number of virtual cores different from the number of full cores. Such CPUs were once called “Hyper-Threaded”, but are now only called “Threaded”.

If the CPU has 8 virtual cores, but is threaded as only 4 full cores, then there will only be a speed advantage, when running 4 processes. But because processes are sometimes multi-threaded, each of those 4 processes could consist of 2 fully-busy threads, and benefit from a further doubling of speed because each full core has 2 virtual cores.

It’s really a feature of Windows to exploit this fully, while Linux tends to ignore this. When Linux runs on such a CPU, it only ‘sees’ the maximum number of virtual cores, as the logical number of cores that the hardware has, without taking into account that they could be pairing in some way, to result in a lower number of full cores.

And to a certain extent, the Linux kernel is justified in doing so because unlike how it is with Windows, it’s actually just as cheap for a Linux computer to run a high number of separate processes, as it is to run processes with the same number of threads. Two threads share a code segment as well as a data segment (heap), but have two separate stack segments as well as different register-values. This makes them ‘enlightened processes’. Well they only really run faster under Windows (or maybe under OS/X).

Under Linux it’s fully feasible just to create many processes instead, so the bulk of the programming work does not make use as much of multi-threading. Of course Even under Linux, code is sometimes written to be multi-threaded, for reasons I won’t go into here.

But then under Linux, there was also never effort put into the kernel recognizing two of its logical cores, as belonging to the same full core.

(Updated 2/19/2019, 17h30 … )

Continue reading A disadvantage in running Linux, on a multi-core CPU that’s threaded.

Bitcoin-Core P2P Client Has UPnP.

I use a Bitcoin client, which is called “Bitcoin Core“. This is a version of Bitcoin, based on Peer-To-Peer protocols. This version of the wallet-program should not be confused with the Android version, which some people have on their phones, and which is Not P2P.

Several people who use the P2P version of this wallet-program, which builds our local copy, of the global block-chain, on a zero-trust basis, have observed that they leave their client running 24/7, yet that they do not seem to be functioning as a full peer. As a full peer, their computer can act to facilitate Bitcoin transfers. Even when not being used as a full peer, this version of the program will connect with up to 8 other peers – using outbound connections – and will use these connections to keep its internal version of the block-chain – and therefore their wallet – synced with the rest of the network.

So after some time, what people may simply ask is, ‘Why don’t I receive incoming connections, from other wallets, expecting me to help complete their transactions?’ This would be a reasonable question, yet gurus elsewhere have given a wrong answer.

In general, this P2P Node needs to listen on TCP Port 8333. Therefore, what some people expect, is that they need to establish a port-forwarding rule on their router, which forwards TCP Port 8333 to whichever machine on the LAN is running Bitcoin Core. The advice has sometimes been given, that if you forward this port, you will start receiving massive numbers of inbound connections, and will become useful to the network.

There’s a slight problem with this version of an explanation. Bitcoin Core has the ability to use ‘UPnP’, which is also known as “Universal Plug-And-Play”. What UPnP does, is allow individual clients of our LAN to open a required port on the WAN-side of the router, such as TCP Port 8333 if need be. Because some users believe that enabling UPnP on their routers, makes their routers ineffective as a firewall, they disable this feature. This would be, because those users cannot even trust their LAN-clients, in which case the LAN-clients could trivially request forwarding rules, which the operators of such a LAN did not authorize.

The problem I see, is that I, personally, have UPnP enabled on my router, because I believe my actual LAN-clients to be secure, so that according to me, if they want a WAN port number, they can have it. Also, I have UPnP enabled on my Bitcoin Core P2P / wallet-program. Therefore, the LAN-client in question is requesting this Port 8333, and is obtaining it. Yet, I still don’t see a wealth of inbound connections asking for my CPU time.

bitcoin-core-upnp_1

There could be several reasons for this, one of which might have been, that a software-firewall on the client-machine in question could be blocking Port 8333. But I, personally have checked my software-firewall. It tells me that it is allowing all connections to and from my Bitcoin Core client a-okay. Maybe the firewall of some other participant is not?

Answer: The Windows computer my Bitcoin Core client is running on, had the LAN connection set to Public. According to Windows firewall rules, access to this program on the host machine is only granted when the network would be Private. This is to allow quick access to Public networks, which are not trusted, without reconfiguring the computer, while setting up a more-liberal set of rules for Private networks. Changing the network-type to Private seems to have solved this problem.

With certainty, my Bitcoin Core client will not show me any transactions it has facilitated, because those transactions do not affect my wallet. Bitcoin is designed to be anonymous, so that I will only see transactions which affect my own balance.

Dirk