Welcome to Fractal Forums

Hi all,
just wanted to note that I have stopped any MB3D-related development. This has the following reasons:
1. Overall code quality/unreadable code which does not allow any extension without a huge risk and a ridiculous amount of time
2. Lack of serious feedback from users (except of: "I neeeeeeeeeeeeeed GPU support or I will become an angryyyyy birdddd")
3. Expensive development environment required, even if the most of the code is ASM-code
4. Commitments of other people which were never met: many people wanted to be helpful when it started, but nobody actually helped.
5. Serious lack of spare time and motivation on my side
6. Hardcoded limits everywhere, you can not change the number of lights, not the number of formulas, not the number of params of a formula, not introduce any new feature, not anything without having a massive pain everywhere, it is just a dead piece of flesh


Sorry, this are probably not good news to many people, but I think, it is better to say it clear and stop false hopes/promises.

When possible, I will update the software and remove some reported bugs, but please do not count on it. I will even try to finish V1.92 with some more mesh/point-cloud-export-related stuff. But, likely, this will be my last addition.
If demanded, I would rather want to join the Mandelbulber or Synthclipse project.

Best regards,
Andreas

Thank you for all your efforts.
Much appreciate the improvements your blood and sweat has added.

WHat you did do for the program already has been amazing and all your work greatly appreciated. Its too bad you could not be financially rewarded, as it has been worth it to thousands of users.
But speaking for myself
Everything you did was amazing and appreciated
BEst Wishes on everything and anything you decide tro spend time on
I look forward to tne new 3D aspects of Jwildfire

SIncerely

Louis

Yes exactly as Louis said it, thanks from all of us for stepping up and enhancing the program.  All your reasons make good sense.

M3D will continue to entertain users for years to come.




 

Many thanks for stepping in and making such a valiant effort!

Your work made an already great program better.

I'm sure the extra time will only help your work on JWildfire and anything else you pursue.

Who knows, maybe another brave and talented soul will make the effort to pick up the project at some time in the future  (I know the issues involved make that unlikely, but they said the code was so strange that nobody could pick it up where Jesse left it, but you managed some great work!)  (So never say never!)  (Except just then).

indeed a sad note but totally understandable, main problem was the huge investment for the development system that might have stopped most of the people in engaging in any way, for me this was the blocker from the start :(

anyways, as others have said you already pushed the program, and the source remains public?

Yes, of course


Thanks and cheers!

Thanks for your efforts Andreas!

JIT, Mesh Export & Mutagen from a dead piece of flesh makes you Dr. Frankenstein :dink:

If I remember correctly, did you have an early beta with 8 formula slots?
Is it still available?

As for the hardcoded limits, Jesse and DarkBeam have been quite clear about the difficulties.

Maybe in a few years we can unleash an AI Neural Network on the program code. :D

0Encrypted0 already said exactly what I was thinking, Jesse said the code would be impossible to work with, so you already did the impossible!

I am sorry I didn't have more to do any betatest reports (I had the impression a lot of other users did) also sad to hear the stupid response you've had from "people" who only demands things - that kind is only worth ignoring.

Thank you for your efforts Andreas, you did the impossible! ...only thing I had wished for was colored voxel or mesh export :( But there is still so much we can do with it as it is! :)

Cheers
Johan

dito! people don't understand what it is to get your head into 1000s of lines of code. especially someone else 's code.
mesh from point cloud is not easy. your efforts are greatly appreciated.  :beer:

It was somewhat surprising and sad to read your statement the next day after I tried your program. You named several reasons for your decision to quit the game ... they look convincing. Perhaps you are too young to understand that really interesting problems are rare things. Of course, your decision is your right. However, as soon as you mention the lack of interesting and easy-to-implement  proposals for the development of the program, I want to make a few observations.
Firstly, the idea of automatic mutation is very good, because the fractal  surface is very sensitive to changes in the parameters, and manual "mutation" is ineffective. But there are two problems. The first is the optimum camera position deviation, whereby the current image after mutation becomes useless for  quality evaluation of the mutation result. The second problem - the lack of criteria for evaluating the quality of mutation result and, therefore, the choice of the direction of further mutations.
The solution to these problems would be automatic "viewfinder" that selects the camera position on the criterion of the quality of the visual surface. It can be a stand-alone module that accepts  3D field of points - a rough representation  of the fractal.
I have been using this approach for the selection of fractal curves, synthesized with random choise of parameters. My algorithm automatically records videos of creation and decomposition of "successful" solutions, as well as main parameters of synthesis. The results are very convincing.
Of course, I have no right to lecture you, but do not give up work, which is so close to completion. If you will provide the possibility of unloading the cube of rough data, I can help in the choice of the fractal image quality criteria.

Best regard anyway.

Hi, thanks for your feedback. The latter is probably a misunderstanding. It is not that I'm not interested in/challenged by solving problems. In fact this is what I do day by day, being full-time-employed in the field of software development. Additionally, I do maintain a rather large open source project which will receive some major addition this year. And, in addition to all of this: MB3D + the impressions mentioned above.

This is valuable feedback, but unfortunately it comes too late.
I released the MutaGen about 5 months ago and rarely got any serious feedback, especially not from outside the fractalforums.com  

The current state was intended as first version and should receive further additions. Also in regard to points you mentioned, I'm working with mutations for a longer time. But, there was no interest/feedback from others.



But, it is open-source, so anybody can take over :-)

Best regards

Hi, I don't understand a thing about coding or programming, but I totally get that it must be a drag not to get the support you need, especially when it's all done for the love of the art, so to speak. All I can say is thanks. I'm still hopeful, I can see a bright future for MB3D, even if it doesn't develop much further it's a very powerful program and we'll keep seeing a growing number of fractal artists and magnificent pieces of work thanks to it.

Hi, thank you for your comment!
I have finally found the early beta and re-packed it and placed it under downloads. Maybe someone else may also enjoy it. Please notice the warning-notice!

Cheers!

Andreas

Sorry to hear that Andreas  :sad1:
Not that I am a big M3D user (fan of your JWildfire), but it always sad when ones good intentions and creative energy stop because of lack of positive feedback and attention. What you did with M3D, especially in the MutaGen direction is amazing! I am following JWF development since early versions and always are amazed by your strive for extending limitations and exploring new possibilities... Sorry to know it didn't happen same way with M3D.
I respect your decision anyway.

Well, I do love JWildfire.  Not a day goes by or I use it and have great pleasure doing so.  I'm not the one that knows all about mathematics and stuff but I consider it a journey to find out (the hard way) to use everything, every option possible.  Maybe I don't always know what I'm doing but when I like the result I'm happy ;)
I'm really sorry that someone like Andreas doesn't get the support and attention he so absolutely deserves. Who has put such an immense amount of time and energy and knowledge in programs that even people like me without the scientific background are able to make beautiful things and are able to do so.  I want to thank you from the bottom of my heart for all you've done and I wish you all the very best with whatever the future has to offer for you.  Good luck to you and your family!   :beer: :beer: :beer:

A million blessings for your work.

Mutagen is fab!

 :flowers:

Thanks for a job well done Andreas! Just strip the app of anything valuable and incorporate it with JWildfire.

Hi Andreas,

sad news but an understandable decission. The things you have already done are great. Thank you!  :flowers:

Any idea about the DoF speed problem? Maybe it is just a minor bug but it prevents me from doing animations with the latest version because calculation time raises too much.

Maybe it would be the best to collect all the fantastic ideas and start a completly new project with a clean and expandable code. But I doubt that these features are well documented and I doubt there is an enthusiastic developer to kick off such a project.
Lets see what the future brings.

The only thing I can imagine so far: I made some part of the calculation thread-safe, which was necessary for the JIT-stuff. Maybe I will find the time to investigate it.
[/quote]

Yes, but this goes far beyond my ressources, and without the support of the community (I'm referring here to the post of of buddhi, who gets hardly any feedback for new versions of Mandelbulber), it will hardly work ( except the developer has enough interest / motivation by him/herself, in my case I can not develop this for a code-base, which was not created by myself, of course  ).

Cheers!

I am sorry you had to take this decision, Andreas, but I fully understand!
Thank you so very much for all the time and energy you put into my 'most favourite program of all'! You've done wonders for its advancement where I thought no one could enhance this program after Jesse left it.

I have been out of the loop here in fractal forums for a long while and was unaware of the attempts to develop MB3D.
I Downloaded the new and improved version just recently and was glad to see some interesting changes. I also experienced some minor GUI bugs but that could be because I switched to win10. The best thing is the Mutator - great tool for exploring new combos.
Every change that made renderings go faster would have been on my wish list but I understand the difficulties - you cant make a steam locomotive fly like a plane. :dink:
Speaking of speed does anyone know if the M.C renderer has support for multi-core processors? It looks like only one of my is operating during rendering, or is it perhaps something wrong with the cpu... :-\

Anyways, what i really wanted to say, thanks Andreas for your time and effort!

Andreas - I also offer you my thank you!  :)

But I have a favor to ask of you. I know you already outlined some of the problems why you decided to stop development of MB3D. The technical problems. At this point you are pretty much the only person who has deep knowledge of the code base, it's shortcomings, areas that need to be refactored, hacks, etc. Before this knowledge seeps away through the memory sands, can you please write down your thoughts on the following:

- how would you go about restructuring the project if you would rewrite it from scratch
- what would you do differently than what was done initially by Jesse
- list of things that you really wanted to implement (to finish), but never got the chance
- UI decisions
- roadmap - where did you want to take this project (think back to the time when you just started on it, and was very enthusiastic about it's future)

You input will be greatly appreciated.

The main problem is not the structure (there is not much structure at all), but the unnessarily cryptic code with lots of hardcoded and undocumented numbers inside of it.

I think, using of constants and more comments would help a lot, making the code at least human-readable (try to replace all occurences of "6" in the whole code by an constant, but only the 6 which depicts the number of lights, the other 6 is the number of formulas ;-)) After that it could be refactored, and OO techniques could be applied.


Another major (maybe the worst) problem is that most formulas are not documented and are only available in ASM-code. This makes it nearly impossible to port MB3D to another language, or would make it at least to a very time-consuming task. I. e., throwing all the main code away and starting from scratch, creating a new UI should be a fun thing, but after that, the program would be "naked", not having all the formulas!
In my experience, users already notice it, when only one formula is missing ;-)

The thing what really hurts me is the file-format, which is just a kind of a dump of the internal structures. And there are even multiple file-formats as you know. Any internal change will potentially affect the file formats. And you must always support all versions of them, at least this is currently the case.

User-defined (JIT) dIFS-formulas. Did not work because MB3D used some non-standard-way to call dIFS functions.

I never got used to the UI by myself, I think I would have created a very different one, which does not mean that it would have been better. Especially only one editor window with easier access to all the properties.

I primarily wanted to enable the users to use more formulas and more lights, and to define their own formulas. It was initially clear to me that MB3D is a dead project because of the dead plattform (Delphi, Windows 32 Bit). The BulbTracer and MutaGen-stuff were just additions for fun which could be done easily because they are new code.

I hope this answered your questions well and not any part is taken as Jesse-bashing in any way, which was and is never intended by me! Doing a software-project like this always deserves respect, and hindsight is always smarter! :D


Cheers!

From my experience, many big projects, especially when evolve a lot, reach some point where further improvement is anymore possible. One good example was my Mandelbulber v1. At the beginning it was very small application without any GUI. Then when I got some interesting 3D fractals I started to develop GUI and many effects and options. It worked quite well at that time, because GTK was very flexible, but.... Unfortunately I had no good UI editor, so all the interface stuff was hardcoded. It was very difficult to redesign the UI. Another problem was handling of growing number of parameters, especially when they were needed to be morphed in animation, saved/loaded from settings files or animated by sound. Every part of this stuff needed to take cake about each parameter separately. Only what I achieved was automatic morphing of all floating point variables. But I had to be very careful about order of variables in data structures. There was additionally many hardcoded numbers, which caused troubles when I decided to change something. All of this kind of stuff stopped me in dead end.
That's why I decided to leave Mandelbulber v1 project and start developing Mandelbulber v2 from scratch. I decided to use another framework (now is Qt instead of GTK) and to create internal dictionary of fractal parameters. That two main changes allowed me to reach new flexibility level and full multiplatform support (Linux, Windows, OSX; qmake, cmake, VSC++).
Dictionary of parameters allowed me to simplify loading and saving of parameters in different formats, to morph them in animation using different functions, to automate synchronizing of variables with interface and made flexible animation interface. Now I'm happy of that decision even if it took me 2 year to get similar functionality like old program.  After that it was easy to jump to advanced level (like material management or more advanced animation)
Another benefit is more readable code, which is now developed not only be me, but also by zebastan and mclarekin.

Another example which I can give you from my experience is from automation industry. When you develop any prototype of machine, you never should use the same construction for regular production. The reason is the same. Prototype is never good and level of changes needed to industrialize the process is too high or even sometimes impossible. That why in most cases there is designed new machine based on knowledge gained during development of prototype.

I think there is the same with MB3D. Actually all operating systems are 64-bit, so there is no bright future for 32-bit applications. With actual choice of programming tools and usage of assembly code there is no possibility to convert this application to 64-bit or to another processor like ARM.
The program structure is closed and many things are hardcoded, so scalability of the program is limited.
Even if it is GREAT program and THE BEST, it would be better to start new project or use knowledge and solution in some of actually developed applications like JWildfire, Fragmentarium (or Mandelbulber). I can imagine how difficult is this decision.

Looking at the source code in https://github.com/thargor6/mb3d (https://github.com/thargor6/mb3d) repository, several things jump at me:

• The project is huge! Using https://github.com/AlDanial/cloc (https://github.com/AlDanial/cloc) utility we can see that it has 88 548 lines of code. Almost ninety thousand lines! Amazing  :)
• Lack of comments. No way to tell what each functions does, except by guessing from it's name.
• There is so much commented out code.
• 8 227 lines (about 10%) of the code is in assembly language. See all of the asm lines here https://gist.github.com/valera-rozuvan/28a0ec1dd706a66cf1f08138939d0db1 (https://gist.github.com/valera-rozuvan/28a0ec1dd706a66cf1f08138939d0db1). I compiled this out of curiosity (using Emacs macros). The cloc utility doesn't report number of inline assembly code.

I do understand why the original author wrote so much in assembly. Delphi (pascal) is not exactly a fast language. So, as much as possible, you want to do the heavy lifting in asm, when creating a Delphi program. I used to do just that, back when I did Delphi 10 years ago.

I think this project can be rewritten in pure C (with QT for the UI) in about 3 years. That's a best guess scenario for a one-man effort, doing 20 hours of programming a week on average.

thargor6, Buddhi - what do you think of my estimate?  :)

You are wrong about the amount of ASM-code. Much of the ASM-code sits inside the formula-files which are not even ASM-code, but compiled binaries, e.g. CylinderHeightMap:
I. e., you have to disassemble this in order to get the ASM code.


I would never rewrite the application in C/QT, because in Mandelbulber there is already a project which uses this plattform.
So, it would make much more sense to contribute to Mandelbulber (which I think about, but currently I have no spare time because of my own project).

I can not really judge your estimation, but measuring the effort in years is the right way ;-)

Cheers!

Where is CylinderHeightMap located? Looking through https://github.com/thargor6/mb3d (https://github.com/thargor6/mb3d), I can't find a file named "CylinderHeightMap". Also a recursive search for the string "CylinderHeightMap" doesn't return anything...

OK. Silly me. I should have thought of looking in the release directory [1] also. Found that file inside the folder M3Formulas. So, is the repository https://github.com/thargor6/mb3d (https://github.com/thargor6/mb3d) only responsible for generating the executable Mandelbulb3D.exe in the release directory?

Also, another question. What software was used to compile the code found in the formula-files? Was it a straight Delphi ASM to binary compilation?

---

[1] By release directory, I am talking about everything that's inside the ZIP file found at http://mandelbulb.com/2014/mandelbulb-3d-mb3d-fractal-rendering-software/ (http://mandelbulb.com/2014/mandelbulb-3d-mb3d-fractal-rendering-software/).

Yes, as already written in my initial response: formulas are a major problem.

The formulas are created in a manual process involving some arcane black magic and (almost) unknown/forgotten tools.

Our member Luca could tell a lot of stories about this. Maybe, the process is somewhere documented at this forum, but usually only Luca does this stuff.


Btw, you told that you can understand why to write ASM rather than Delphi-code and that Delphi is slow. Do you have experience with this (I would be really interested in this topic, to exchange serious facts) or is this just an "opinion"?

Cheers!

It's not just an opinion. I am speaking on the basis of my experience writing Delphi code about 10 years ago. Back then, 32bit computers and 32bit Delphi were still relevant. As anyone who programmed in Delphi knows, Delphi compilers use their own Object Pascal dialect of Pascal. Although not an interpreted language (Delphi does generate native code), I did look at it as an inferior language, compared to C. Why? I stumbled into the fact that Delphi generated very slow/inefficient code for floating point arithmetic operations. So most of the time I converted everything dealing with floating point math into ASM. I did do profiling, and the difference was very much noticeable. Unfortunately, now I don't have the software or the actual profile timing results.

Here is some interesting reading material on this very topic:

• Benchmarks! FPC vs Delphi vs C++ (http://www.pascalgamedevelopment.com/showthread.php?4896-Benchmarks!-FPC-vs-Delphi-vs-C)
• Is it possible to clear the FPU? (http://stackoverflow.com/questions/33527760/is-it-possible-to-clear-the-fpu)
• Floating Point Optimization Comparison in Delphi 2007 and XE3 (https://helloacm.com/floating-point-optimization-comparison-in-delphi-2007-and-xe3/)
• First look at XE2 floating point performance (https://www.delphitools.info/2011/09/02/first-look-at-xe2-floating-point-performance/)
• Coding for Speed in Delphi (http://www.dennishomepage.gugs-cats.dk/CodingForSpeedInDelphi.doc)
• How to use modern CPU instructions in Delphi? (Java faster than Delphi?) (http://stackoverflow.com/questions/18610419/how-to-use-modern-cpu-instructions-in-delphi-java-faster-than-delphi)
• Which Delphi compiler produces faster code? (http://blog.synopse.info/post/2011/06/16/Which-Delphi-compiler-produces-faster-code)
• How to optimize this Delphi function with SSE2? (http://stackoverflow.com/questions/10126198/how-to-optimize-this-delphi-function-with-sse2)

Here are some quotes:







Anyways  :) I believe that before doing any optimization by converting code to assembly, one needs to first make sure the algorithm is optimal. Also, it's very important to do profiling. To actually measure how much efficient your code becomes after some "optimization trick".

For those of you who stumble in the future on this post. In the hopes to make it easier for you to understand how MB3D formulas were created. A collection of posts with bits and pieces on the "manual process involving some arcane black magic and (almost) unknown/forgotten tools.".

• Custom formulas & transforms - WIP & discuss (http://www.fractalforums.com/mandelbulb-3d/asking-permission/)
• Quick formula question (http://www.fractalforums.com/mandelbulb-3d/quick-formula-question)
• Blobby (How to write simple m3f) (http://www.fractalforums.com/tutorials/mandelbulb3d-tryout/)
• Writing formula using gcc (Re: Blobby) (http://www.fractalforums.com/tutorials/re-blobby-reknighty)
• Benesi "pinetree" (fold+bulb) (http://www.fractalforums.com/new-theories-and-research/do-m3d-formula-have-to-be-distance-estimation-formulas/)
• writing a mb3d formula (*directly* in Assembly) (http://www.fractalforums.com/tutorials/writing-a-mb3d-formula/)
• A few formulas (For Luca... :D) (http://www.fractalforums.com/mandelbulb-3d/a-few-formulas-(for-luca-d)/)
• Experimental MB3D-version with integrated formula-compiler (JIT) (http://www.fractalforums.com/beta-testing/experimental-mb3d-version-with-integrated-formula-compiler-(jit)/)
• teeandy: Mandelbulber3d :d (http://teeandy.blogspot.de/2015/11/mandelbulber3d-d.html)
• How to code a formula for M3D (http://www.fractalforums.com/tutorials/how-to-code-a-formula-for-m3d/)
• How do I program difs shapes (http://dark-beam.deviantart.com/art/How-do-I-program-difs-shapes-526007462)

To actually see implementation of custom formula loading, execution, etc. go directly to the source of MB3D:

• FormulaClass.pas (https://github.com/thargor6/mb3d/blob/master/FormulaClass.pas)
• formulas.pas (https://github.com/thargor6/mb3d/blob/master/formulas.pas)
• CustomFormulas.pas (https://github.com/thargor6/mb3d/blob/master/CustomFormulas.pas)

So ... anyone up for a rewrite of this project?  :)

Hello, i would like to participate of this project. I'm not a coder but i am 3d graphic designer and i can help you for the ui design.

Awesome! Come take part in the discussion of the project rewrite over in the thread Remake of MB3D (http://www.fractalforums.com/index.php?topic=24293.0).

OK, I had just to ask because I do not know you. The current MB3D-version is compiled using the XE 6 - compiler, so I was interested in more recent comparison results.
But, I also think that even the newest versions seem not have received major updates regarding the floating point arithmetic stuff.

I agree, a lot of wrong design is made because of "premature optimization".

Cheers!

Well, I've been using Delphi 7 for many years, too. Analyzing the native code created by the compiler shows it was quite high level language, I mean, Pascal lacks many things C/C++ have, being closer to the raw meat - by design.
But even putting this aside, as you know, this language is almost not evolving, while C++ lives its another spring :)


Yup. For C/C++ we do have really many interesting maths libs available, just to name one: Intel lib, but also many others.


This! So much very this...


BTW, I could help, but I'm already in another time consuming project (rewriting Apo from scratch...) and I'm really busy with my regular job. So, at least in this upcoming year - I'm out  :sad1:

I wish you much luck with this project as I really know how much work such stuff is :-) Let me know when you need some beta-tester.

Cheers!

Convert it to Lazarus ?
https://github.com/thargor6/mb3d/issues/7