You can make a Curriculum bullet-proof, by beginning it with a strong hardware-level statement:

always @ ( posedgeclock) beginstatus <= ~status ;end

I'm Simon Hasur, male, born 1989, in Europe (Hungary).

After having clamorously failed in everything I've ever tried, together with a disastrous school career, I came to the programming of simulators, initially in * Matlab*, then in

I soon got particularly interested in the

Since my main interest was

I then implemented a

My

During the time I did these things, I progressively became interested also in

As a result, in the subsequent 2 years or so, I deviced 6 theorems in the field of Algorithms, which together make this possible. And form a complete theoretical framework to polygonally approximate, analyze, random-generate, and render in real-time terrains or surfaces in general : a

The implementations of my terrain-rendering Algorithm's 3 flavours into

Detailed information can be found at my website:

www.nerdofalgorithms.altervista.org

The most significant flavour of the Algorithm is the

Algorithms almost literally saved me: things weren't going too well for me in real life, where in fact I was nobody, and the only certainty which remained for me was the scientific method... ; but thanks to Algorithms, beside using that method, I also made a name for myself and created a purpose for my existance, which had been useless all the time before.

Beside the heavy reasearch and discoveries it has lead to, I also made many videos concerning various from my fields of competence: this because scientific communication is crucial to make the theoretical and practical tools available to those who may benefit from them. Hope to do more in the future. I also made a remake of the first

Now I'm 26 years' old.

I recently came to the end of the nearly 7-year long degrading phase of a neurodegenerative illness ; because a cure was found to arrest or reduce to infinitesimal its worsening. I had noticed that a change had been going on in my personality during the past few months, probably due to heavy neural alterations ; and at the point the illness was stopped I was, de facto, already a new person. What was not altered anyway was the fact of being driven by a calling towards the scientific method.

I noticed that what really had changed, beside a heavy change is personality, was that I did not hate mathematics so much anymore, and had a very strong interest in it, and that most of my many doubts about it seemed to have disappeared. Maybe the brain, in an attempt to resist to the degradation, had produced massive amounts of new neurons, which now, after the cure started to be administered, were fully equipped and ready to use: I can't be sure, but I like to think of it this way.

I understood that I just had to apply the definition, and use the resources put together by the person I was before, and add my new ones. And go on solving problems and devicing methods like a Bulldozer pushed at maximum gas. Now not only in *Algorithms*, but also in *Applied Mathematics*.

I realized that now, beyond *Numerical Methods*, I had a very strong interest also in the entire theoretical background of *differential equations* and all their applications.

I wanted to contribute to it. So I took my first theorem on Numerical Methods, and realized that it could be used to device a very fast method to numerically simulate mid-oscillations (oscillations a bit larger than the small-oscillations) of dynamical systems. I deviced the method, and proved that it's correct, in my **2nd theorem** on *Numerical Methods*. A theorem which defines, beyond the numerical method itself, also a very class of differential equations.

Using these results, I plan to create soon a small software-package to do fast simulation of 3D articulated bodies exhibiting from small- to mid- oscillations.

While creating detailed documentation and guide to the use of the articulated-body simulator I created years ago and reently released as free and open-source software, called *Lagrangian Dynamics' New Flavour Simulations*, I discovered and deviced also a theorem on Analytical Mechanics. Soon later, by revisiting the facts realtive to that and relative to my 2nd theorem on Numerical Mehods, I deviced my **1st theorem** on *Differentil Equations*, which defines a class of differential equations of systems of them, which I called *"polynomial systems"*, whose features are the ones which grant the correct and reliable funtining of the *Lagrangian Dynamics' New Flavour Simulations* simulator. That theorem and the theorem on *Analytical Mechanics* is discussed in part 2 (out of 3 of its documaentation- and guide- video and its written transcribtion (when it becomes available).

Now I'm fiddling around with some special partial differential equations and am working on a 3rd theorem of mine on Numerical Methods. And on some new techniques of semi-realistic 3D animation, to use in videogames or plain 3D animations or scientific visualization.

As to the development of videogames, I plan to do soon a new flavour of New CTruck3D Rally game: a variant set on a randomly generated terrain supported by the Heigh-data Injection Enabled New Terrain System algorithm I developed before.
Recently, I became interested also in making 2-3 mini-games: using some of the new semi-realistic animation techniques I've been experimenting with lately.

To conclude this presentation, I report one of the favourite quotations of the person I was before:

*"Given the state of our modern Heartbreak House, I fear a victory not of anyone's intelligence, but of the pig and the rat."* (Andrew Hodges, 'Alan Turing: the enigma' [1991])

And a simplified scheme of how my activity went on in the different fields it dealt with:

/--->Videogame development----------------------------\Videogames--->( )--->Algorithms+ Applied Mathematics <---- neural damage \--->Simulators--->Numerical methods used in them---/

In the rest of this curriculum You find an ordered collection of short describtions, one for each problem or problem-area which I solved and deviced some computer-program with it: most of the describtions feature also a video which shows the things more directly, and go a bit more in detail than the describtions. After all, in scientific communication text, figures, formulas and even video footages feature togather because the communication must be as univocous, clear and priceise as possible. So why should it be too differently in a curriculum oriented to scientific activity?

Enjoy!

date: July 2015

place: Lecco area, Italy

Follows a list of solved problems, presented in a templated form with a video and an impression-image at end of most sections.

Creation of a bunch of mini-videogames, all written in JavaScript ; which gradually I published on GameJolt.com

I made a bunch of mini-videogames, all written in JavaScript, which gradually I published on GameJolt.com, at the following link:

http://gamejolt.com/@ctrucker

This because most of them are also example-programs featuring in my text-book on Programming, Math, Algorithmics and some Physics, which I am writing.

Useless to say that I got graually an interest in dydactics, pedagogy and scientific divulgation: reason why I updated my website and opened in it 2 new sections: one which collects all my divulgative short-essays, and one containing my text-book entitled Applied Mathematics and it's Applications ; as far as it has gotten at the given date.

video attachment n.17:

https://www.youtube.com/watch?v=iemSs_2OYrM

Exposition in a 68-minute video, of my 5-th theorem on Polygonal Surface Approximation, at the heart of the Height-Data Injection Enabled New Terrain System Algorithm

I exposed in video my 5-th theorem on Polygonal Surface Approximation, at the heart of the Height-Data Injection Enabled New Terrain System Algorithm. An 68-minute exposure done with HD video and HD audio, featuring a cosiderable number of figures with some usage of colors to make it all more clear and involving. So that the overall product, thanks to the HD and color-faithful video technology, is really enjoyable.

video attachment n.16:

https://www.youtube.com/watch?v=_mKK-bNdSQU

Development of the FalansterCity3D urban environment renderer, fully written in JavaScript and using HTML5's standard 2D graphical library only, to make it compatible with all systems... just an Internet-browser is needed to run it

Seen the compatibility prolems of the graphical libraries for the C and C++ programming-languages, I learned a more modern development tool: the JavaScript programming language, which through the HTML5 standard, interfaces excellently well with a simple HTML document. And runs on all systems as long as they have a common Internet-browser. Since it so feaures standard- input and output in real-time and also 2D graphical output with hardware-acceleration wherever available, this is a major step in the combatment against software-compatibility.

I then developed a full 3D graphical library for JavaScript + HTML5. Besides 3D graphics, it does also other things... it's a true 3D urban-environment renderer, for whatever use one wants to make of it.

It is called FalansterCity3D.

And is fully open-source and can be tried directly, or be downloaded, from the following link.

http://gamejolt.com/games/falanster-city-3d-a-browser-based-gta-clone-and-urban-environment-rendering-engine/163983

It can also be tried on my website, but check always the version-number as I tend to update more frequently the program's page on GameJolt.com .

One can also try out routes in a cityside environment, as there a cars featuring semi-realistic physics.

The most crucial thing about the whole product is that it uses my first theorem on 3D rendering to render curvilinear, 3D segments of roads. So, it does the seme things that did my older similar project, the "Map System" library, but it is more powerful and can display some simple-shaped building too, and detect collision of the semi-realistically simulated cars with them.

It's also very fast, as thanks to that theorem, it can exploit Bézier-curves to render segments of multilevel networks of roads, at the modest cost of 4 polygons per each segment of road. Another theorem of mines gives the guidelines to design environments so as to enfoce always correct hidden-surface removal: something which can also be automated ( even though this feature is not implemented yet in FC3D as it's primarility designed for top-down view where the proplem of correct hidden-surface-removal is not defined as it comes out practically always corretly, by itself ).

video attachment n.15:

https://youtu.be/UOa_6onalQs

Creation of detailed documentation for the

I created detailed documentatin for the *L.D.N.F.S* articulated-body simulator: in form of video, as well as text (in HTML fortmat for easy online-reading as well as printing, with figures drawn by me and nice HTML tables ).

While doing so, I accidentally discovered some facts about the Lagrangian Equations of Motion and their use in a numerical simulation. I investigated a bit, and deviced my first theorem on Analytical Mechanics and my first theorem on Differential Equations: although the simulator doesn't need theme as it relies only on my first theorem on Numerical Methods to function, these other 2 theorems come in very useful for a clearer and much more solid documentation on how the software works.

All information is on the default homepage of the simulator, *www.nerdofalgorithms.altervista.org*, where it has it's own dedicated section. To be sure, the documentation-videos shall be linked also on the simulator's page on SourceForge.net for the eventuality of accidental shortages of the *www.nerdofalgorithms.altervista.org* website.

WARNING: the video-documentation consists of 3 parts, as indicated in the titles too! - so don't miss any of them out when all 3 parts are ready. Thank You for Your attention. The documentation book (it's actually like a book) will yet take some time to complete... but it's on it's way: however, since articulated-body dynamics is a topic which interests comparatively few people, some slowness in writing the documentation book is excusable.

video attachment n.14:

https://youtu.be/rcyddXDsE9k

Release (as open-source software) of the articulated-body simulator which I have developed years before ; now tidyed up and reverted into its implementation in standard

I released (as open-source software) the articulated-body simulator which I have developed years before ( described in experience-point n.3 ) ; now tidyed up and reverted into its implementation in standard **C**. I have called the simulator *Lagrangian Dynamics' New Flavour Simulations*: the documentation-page is on my hompage *www.nerdofalgorithms.altervista.org*.

For a quick overwiev of the simulator, I made a short video-presentation of it, linked below as well as on it page on SourceForge.net .

video attachment n.13:

https://youtu.be/CnyZZZgzrrg

Development of a fast simulation method for articulated bodies exhibiting mid-oscillations (i.e.: for the simple pendulum, stay withing 60 degrees displacement). It's reviewed by my second theorem on Numerical Mehods.

A sort of neural problem in the brain, I had been battling with for a few years, had culminated before being arrested by a chemical cure which was discovered. I realised that I was changed a lot. As a matter of fact, I was a new person: probably because of some neural alterations which the illness eventually produced. Anyway just a change of personality, however heavy it be.

What was not changed, is the fact of being subject to a sort of constraint-force driving me to stick to the Scientific Method.

I soon realized that what had changed instead was, that I did not hate mathematics so much anymore, and that most of the doubts I used to have about it, had disappeared.

I had now an utterly strong interest in Applied Mathematics.

By simply applying the definition, I understood that it was time to act.

And just as a many-tons airplane at some point gently takes off and a new landscape to discover is in front of it, I had turned into a new person and a new life, full of discoveries, was in front of me.

So. I rewised complex analysis, and begun to explore more advanced topics on differential equations, and wanted to contribute : I realized that my first theorem on Numerical Methods could be used to device a very fast way to numerically solve for the Lagrangian Equations of Motion in the case of a 3D articulated body (or anything similar), in the case it exhibits mid-oscillation (oscillations a bit larger than small-oscillations). So, I deviced a second theorem of mine on Numerical Methods: which defines the above-mentioned method, and allows also to analytically study the equations of motion. As a corollary, I added the way to generalize the method to systems of n-th order differential equations, which so define also a new class of not-so-complicated differential equations.

With this results at hand, I plan to make a nice small, minimalistic C++ module to do fast simulations of articulated bodies exhibiting mid-oscillations. Since in the meantime I had been playing around also with various types of differential equations, some ideas occured to me. I also resumed in fact an idea I had had in the past few months: devicing some semi-relistic animation technique for articulated bodies.

I have now some results I am going to test soon, for 2 different areas: 1 method for 3D articulated bodies, another for the animation of either cloth-like things, flags, tissues, or things like ropes.

Since the purpose of these methods is to provide a simple way to achieve some compromize between serious realism and just good look, I became interested in making mini-games too.

In the meantime I also deviced an alternate proof for my first theorem on Numerical Methods. It's nice to have 2 different proofs for the seme things: so there is choice for different tastes. After all, it's we, human beings that do the mathematics: and we have different tastes and styles.

To change topic, I also started to evalute some nice application of the terrain-rendering Algorithm I deviced before: I realized that a nice flight-simulator would be the most appropriate.

I bacame interested in aerodynamics too: after all, if a new life has begun, also some new fields of interest must begin, even without deleting the preexisting ones: but just causing them to be seen from a new point of view.

video attachment n.12:

not made.

Creation and release of a variant of the

I investigated the *Simplified Terrain System* Algorithm I developed before, to see if random data could be *injected* into the procedure from time to time, to literally *simulate* the rendering of a heightmap which can be accessed in a fully ideal full-streaming fashion. An investigation I undertook because with the standard algorithm (the *New Terrain System* Algorithm as it is referred to in the paper documenting both variants) would make it very hard to *inject* height-data into the polygonal surface representing the terrain, as detail is added in some region of it.

I deviced my **theorem 5** on *polygonal surface approximation* to prove that it's possible, and to get to the procedure which say *how* to do it.

The landscapes it creates look fairly natural: so the 'experiment' - so to speak - succeeded. For the rest, the seme things hold true as for the Simplified Terrain System Algorithm: details are found in the paper documenting it (on www.nerdofalgorithms.altervista.org) and in the previous point of this Curriculum (and video attached to that point). Very important the video here, so let's cut the verbal expalation short here.

As I stated in the previous point, the variant of the terrain-rendering Algorithm at the basis of this one *cheats* - so to speak - while going from one distribution of more and less detailed areas ( a *blockset* as it is called in the paper), to another. It cheats in as much it can not add detail everywhere, but only in a special subset of regions. This is not a problem itself since such 'cheating' solutions mekes the overall Algorithms faster ; but rather than saying that it's not a problem, I wanted to outline the extent to which this fact of cheating impacts on the visual quality of the polygonal approximation of the surface as it changes dynamically.

After considerable amount of theoretical investigation, I deviced a theorem, my **theorem 6** on *polygonal surface approximation*, which grants that the Algorithm works always well, even if not always equally well. It also oultines how much 'flexibility' it currently has in changing the amount of detail the various portions of the surface being rendered. This is a very interesting point, but this is not the place to discuss it.

So, said shortly, the nice thing is that not only the rendering system works as expected, but also that the theorems underlying its operation, namely my theorems n. 0,2,4 and 5 on *polygonal surface approximation*, provide a full and complete framework to work with polygonally approximated surfaces, including static and semi-random surface-modeling, alongside with real-time rendering of it, clearly.

While **theorem 6** says how and why it works and in which contexts ; and says that the theoretical and practical use of this framework in the context of polygonal surface approximation (or computational geometry more in general), is equal to that of the *Laplace-transform* in the context of the theory of *differential equations*.

video attachment n.11:

https://youtu.be/2R5sLfQAtMs

Creation and Release of the implementation in C++, of a simplified but faster variant of the Terrain- Rendering or

I had the idea that *step 3* of the the terrain-rendering Algorithm I developed before (referred to as *New Terrain System*) could be replaced by a series of checks put into step 1 and 2 to *cheat* in the way to enforce the passage from a *legal* blockset to another legal blockset. I deviced my **theorem 4** about polygonal surface approximation, and using it, created and implemented (in **C++**) the *Simplified Terrain System* Algorithm.

Beside being considerably faster than the original Algorithm (referred to as *New Terrain System*), it has some rally interesting properties, which are not discussed here but are adressed in the video-attachment and in later investigations.

video attachment n.10:

https://youtu.be/j0cEMqJje9w

Release of the implementation in C++, of the Terrain- Rendering or polygonal surface-approximation Algorithm which I deviced throughout the past 2 years

I released the implementation in C++, of the Terrain- Rendering or polygonal surface-approximation Algorithm which I deviced throughout the past 2 years. It can be downloded from the following link:

https://sourceforge.net/projects/newterrainand3dmapsystem

Both the multi-threaded and the simple implementation are available.

Furthermore, there are other 2 packages in which, upon the terrain there's the module for the visualization of a multi-level network of roads. A module which I had developed before (You find a describtion of it, which video-attachment too, in this curriculum)

For this, I added also a little module which puts some trees here and there on the terrain, to make it look more natural.

There's also a composite package in which, above the terrain (with possibly a network of roads on it), it's possible to go around with vehicles featuring semi-realistic motion.

The documentation and the release of a simplified version of the terrain-module is being prepared. This notwithstanding, the developments don't finish here, because meanwhile I accidentally discovered another property reguarding the poligonalization-scheme of a surface, used by the Algorithm: and I am devicin my **4th theorem** on *polygonal surface approximation*. A theorem which should make it possible to device a simplified version - which works well anyway -, which is a bit lighter than the orignal one, but which is simpler, shorter, and which does not need the first theorem, which is a bit problematic.

This, beyond the importance from a theoretical point of view, consitutes a turning-point from the point of view of a clear and simple documentation. A documentation which may be also certainly funny for many: provided that after a simplified variant of the Algorithm, the full variant is easier to understand inasmuch the underlaying concepts have already been introduced throughout a simplier Algorithm, which, however, differs from that only by one passage... which passage, however important it may be, is only one single passage.

video attachment n.9:

not made.

Learning of 2 new professions, to adapt to the Jobmarket's severe crysis: web development and development of digital systems using Verilog as main design tool, on an FPGA board

Having clearly seen that the job-market for men called to Algorithms at heavy depths went down, I moved on to learn parallelly 2 new professions ;

without of course any intention to ever stop dealing with Algorithms. Read the more recent point to find out what I did in Algorithms meanwhile.

1. with the help of a friend I learned the basics of Web development with PHP, SQL, HTML and SVG (for the graphics).

Then I created the site designed to host the ever first scientific articele featuring figures procedurally generated with PHP scripts: "The Nerd of Algorithms",

www.nerdofalgorithms.altervista.org

.

A site intended to serve as a sort of *nerds' paradise*: a portal of various materials concerning Algorithms at various depths, 3D Rendering, discussions of nerd life, up to Numerical Methods, dynamics of articulated bodies (mostly Lagrangian Dynamics) and videogame-programming.

2. Parallelly with point 1, I moved on to learn the development of digital systems with FPGA technology, using the Verilog hardware-describtion-language as the primary design-tool. Aiming at reaching a discreet level of ability in this field.

It may seem rather casual as a step, since most people who deal with FPGA technology are engineers, while I'm usually seen as a theorist. But actually the decision was the result of a lenghty and careful evaluation done with scientific method. And not a quickly improvized decision done under the disorienting effect of the job-market's severe crysis here in Europe. If anything, Verilog and FPGAs is something so different from my usual fields of activity, that at least it introduiced something new.

Not being 12-16 years' old anymore, it was all more difficult: I needed to go throught a very intense training to arrive at something meaningful. As You may know, Verilog is considered difficult becuase it's intrinsecally massively parallel - while no of the typical programming languages to which an algorithmist is used to, is really like this. And thus a consolidated practice with Algorithms and programming languages such as BASIC, C of C++, can be more evil than good. Because Verilog looks similar to a programming language, but it is not: it describes hardware, it describes a digital system ; and not anything like a procedure.

As a theorist, I followed a deductive approach, being very careful not to miss out anything vital. At the beginning I just went through the chapters of a book teaching the basics, but I knew that most substancial part of the task would come after that.

Most material on Verilog in fact discusses it without gradually introducing the Reader to parallelism in digital systems, neither does it discuss much how to use it to develop systems with an FPGA at hand. Even if these things are vital.

So I deviced a true teaching-programme to teach it to myself efficiently. So, I set myself to develop, using an FPGA, a full-featured VGA monitor driver with incorporated text-output and at least some 2D, hardware-accelerated graphics. Which have a hard-wired part that, assuming the use of 1 or 2 CPU-based units to run Bresenham's line-drawing Algorihtm, produces filled triangles at very good speeds. A simple architecture in which there is some parellel memory management, and there are also sequantial parts where correct synconization is vital.

A simple system, but enough complex to get me heavily into the stuff.

I soon encountered the typical problems of designing complex digital systems in fact: most importantly the phenomenon of metastability, to be avoided by doing a good timing of how information propagates througout the system. It was a true frontal collision, since most books on Verilog only mention it marginally and discuss only very simple systems, which clearly fail to cast light on how to behave while designing something more complex.

Eventually I learned at least discreetely how to diagnose metastability, and how to find out its cause, and finally how to work out a good design which avoids it. I also familiarized further with Verilog's intrinsic parallelism: the only thing which I had got right about it at the beginning.

It took me several months, and I found it very difficult ; but eventually it worked fine: that's why it was all not a casual decision to try learning it. Since also theorists can do some good with FPGAs ; if anything, the design of digital systems with Verilog is very challenging because it's so different from Algorithms or programming or anything like that.

video attachment n.8:

not made.

Creation of a 3D, free-roaming off-road racing game using the C++ programming language ; combining the Terrain- Rendering Algorithm I developed before and some semirealistic car animation

I took the multithreaded C++ implementation of the Terrain- or surface- Rendering Algorithm I developed before, and used it to make a full renewn remake of the first 3D game I made several years before, a racing game called CTruck3D: the remake is called New_CTruck3D_Rally. It can be downloaded from here (in form of C++ sourcecode ready to compile on *nix systems):

https://sourceforge.net/projects/newctruck3drally/

Usually men called to Algorithms don't have time and enegy left for making videogames, even if an Algorithm's potential is often best illustrated by what it can do in a videogame.

But I had the semiralistic car simulation- and animation- routines already ready to use from the time I wrote them packed in C++ classes when I was yet a Videogame nerd and had not yet become a nerd of Algorithms. So I just did the effort of combining togather the 2 modules: terrain-rendering and more-less realistic imitation of a car's motion. It has al the most crucial funcitonalities, but I hope anyway to release soon a more refined version.

Well, a tribute to videogames is absolutely worth it, however hard it be: even becase I came to Algorithms from videogames.

Have lots of fun!

video attachment n.7:

http://youtu.be/I3QvCTdxryE

Implementation (in C++) with multithreading of the terrain- or surface- rendering Algorithm which I developed before in a sequantial fashion.

I made an enhanced implementation of the previously developed Terrain- or Surface- Rendering Algorithm, using multi-threaded programming (with the C++ programming language as usual in my case). It's really better, just as I had expected.

For the full describtion, please have some patience: I will insert it later.

Anyway, there is the video-attachment: and I've put quite some effort in making it clear, nice and fun: the video attachment is funnier than a short describtion, and of course it also goes into much greater detail on the topic.

video attachment n.6:

http://youtu.be/tTiMxOHMTgg

R&D to get better the previously developed terrain- or surface- rendering Algorithm: now computatinal weight and memory usage were directly proportional to the total amout of detail visualized in the current camera-shot

Using my second theorem about terrain-rendering ( or polygonal approximation of surfaces ), I made the definitive version of the terrain-rendering Algorithm I had developed before.

A simple method which anyone can undersand and use, easily.

This version, by itself does not add anything to the previous one, but makes it lighter (less operations needed for 30 FPS). Both the computational cost, and memory usage are directly proportional to the amount of detail which happens to be in the current camera-shot.

Where "amount of detail" is simply the number of blocks typical of the method ( video attached to the previous exp-point explains this).

Just as it was expected, the computational cost of the Algorithm does NOT depend on the terrain's size ; and the terrain can be as large as desired, of course: which was one of the objectives, since a good algorithm should not put any particular limitation on the size of the dataset on which it operates.

(e.g. a good sorting algorithm doesn't stop at 1000 names to sort alphabetically).

Here is a review-list of the Algorithm's features:

0.Terrain as large as diseired: it is a method which accesses heightmap data in full-streaming. Much over 8k x 8k. For terrains smaller than 8k x 8k instead, it can work out-of-core.

1.Unlimited draw-distance: from a proper spot, the whole terrain can be seen.

2.Memory usage and computational cost nearly constant: max 16 MB of memory circa, and computational cost k*n where n is the numbero of blocks in the current camera-shot. Concretely, on a 2 GHZ computer, until 3000 blocks it goes flawless ; on a 600-1.6 GHZ computer, until 1500 blocks it goes flawless.

3.It adjusts the level-of-detail (LOD) according to the point of view and perspectivic constant: thus it has nearly flawless LOD transitions.

The paper illustrating entirely this Algorithm, is being made: all details which don't fit here, will be provided there. I made a video illustrating the thing at least as an impression ;

for the rest there will follow other 2 papers going into greater detail.

video attachment n.5:

http://youtu.be/-V2z5HChU2o

R&D to develop a new rendering Algorithm tuned for large terrains: one which be fast, and use little memory.

Some time before I had acquired consistent experience with the use of the approach to the rendering of large terrains pioneered by Peter Lindstrom and cooperators ; and I had worked out some enhancements, and implemented them. According to the tests I made, the enhancements were good, but both the implementation and the very Algorithm as a whole was too long and complicated, and the performance was poor as also the abuse of memory was heavy. I gathered some documentation about a significanty enhanced method developed later by P.Lindstrom himself togather with V.Pascucci, but the documentation about it did not suffice to me to use their results directly and moreover I was discouraged by the heavy memory usage which still persisted in the enhanced method.

After some investigation, I found out that the primary cause of the difficulties was the datastructure at the basis of the Algorithm: a tree-like structure... a quad-tree. So I proceeded to develop an Algorithm which arrives at the seme result - a triangulated surface - but through a completely different procedure, much shorter and much more efficient: and one that abandones completely the datastructure and the basis of the original method... the quad-tree.

It uses instead a simple vector (intended as a row of containers of the seme type).

And the number of operations done by the rendering procedure depends rigorously only on the number of blocks currently present in the rendering: where the "blocks" are those of the original method... and as few as 1000-2000 blocks suffice to produce an excellent rendering.

The video-attachment shows the complete program and explains the principle of operation in detail.

The radical change in the foundations required in practice to do everything at the contrary. I did not have other chance than proceeding with mathematical proofs. First I proved that all would be possile as a whole, then I wrote the new (View-Dependent) terrain-rendering Algorithm: but shorter,simpler,and more efficient.

video attachment n.4:

http://youtu.be/fPow5pTVtdc

R&D to establish a collision-detection method for a special type of non-convex polyhedron (very useful for 3D maps)

Research and devlopment about a method of 3D rendering and contact detection specialized in a type of non-convex polyhedron: those typically made up by a usually curvilinear segment of road. I started out from an idea already partially implemented into Algorithm in the C programming language, years before; and tested successfully.

Then I went on to develop a complete and coherent library for the C++ programming language, that provide support for the creation of programs similar to Google Maps(R), but entirely 3D, with a multilevel Network of Roads (so undepassages, high-passages and normal roads all supported with no particular limitations) ; where each segment can be curvilinear, and if needed can have variable width, variable lateral steepiness and other features varying along its path.

The fact of being 3D would not be very useful if the network of roads could not be eased to stay on a more-less rough approximation of the terrain in the nearbies: in fact the support for this is in-built.

The video-attachment shows it all in action.

The purpose of this library was to combine the above-mentioned features with an easy-to-use mouse interface with informative labels overlaied to the 3D scenario, advanced colouring of alternate paths, and of course a little collection of Algorithms for the search of shortest-paths and similar things.

video attachment n.3:

http://youtu.be/R5ACL1bLccY

Research and Development in the field of 3D simulators: development of a simulation-procedure in

Theoretical research followed by implementation of an enhanced variant of the physics engine I had developed before: entirely based on the Lagrangian Dynamics, but this time without any of the weaknesses of this method in its classical flavour, and with a heavily enhanced numerical stability and maximum preservation of the significant digits. Originating so a simulation engine specialized in articulated bodies but without any limitation in this field. I implemented several test simulators with it, of which the most significant was the simulation of a 4-wheeled vehicle, 14 degrees-of-freedom, with no approximations.

I started also to design a variant of the engine software, intended for a possible future release as open-source library separately for C and C++ programming language, easier to use but limited to articulated bodies featuring only typical jointing mechanisms ( prismatic, hinge, spherical, universal ) .

video attachment n.2:

not made.

Programming in C/C++, in the field of Algorithms

Starting from a preexisting basic exposure to 3D graphics- and game-engines, I chose a branch of them to get deeper into. I chose the Terrain Rendering topic, useful for driving- and flight- simulators. Since at that time I had already grown a certain interest in Algorithms in general, I chose a method that be interesting as such: I favourited the approach pioneered by Peter Lindstrom and company, I wrote it in C++ from zero, and eventually I adapted it implementing a procedure that be optimized and particularly sharpened to be run "in background" thanks to multithreading. I acquired even further practice with the OpenGL graphics library. The Video-attachment shows and comments it.

Frequenting that method, a quite colorful algorithm, had sharpened my sense and interest for the field of Algorithms, in a broad perspective: so, after this experience I've always spared some time to commit to Algorithms, including Numerical Methods too, with particular reguard to Optimization and the exploitation of Multithreading.

video attachment n.1:

http://youtu.be/VHIG6LF82kg

Research and Development on the possibility to apply the Lagrangian Dynamics in the numeric simulation of the motion of 3D articulated bodies, and programming in C/C++ of a simulator based on that method

Research and development on the possibility to apply the Lagrangian Dynamics to the simulation of articulated bodies in 3D videogames and similar applications ; followed by the effective implementation in the C programming Language of a simulation procedure (physics engine) entirely based on that approach. It was fully functional but still had 2 weaknesses typical of the Lagrangian method: implementing various test simulators, I had started to evaluate the possibility to develop an alternative variant that have no of theese weaknesses.

To get ready for a second stage of research and development, I encapsulated the physics engine devised, into a class of the C++ programming language : this contributed to make the future developments faster. In short, I had laid the foundations for what later became by main area of expertise. I went heavily into Numerical Methods and the question of Optimizaion (speed of execution / performance of the software).

Moreover, the use of the Generalized Coordinates - intrinsic to the Lagrangian method - had sharpened my attention towards the effect on simulations, of the limited number of significant digits that each variable has in a numerical simulation.

video attachment n.0:

not made.