Welcome to Fractal Forums

Hi all,
I have been criticized to not already outlined a bunch of ideas how to contribute to the MB3D-project and not have been proved my "coding chops" yet :D

Okay, to be honest, I have MUCH underestimated the tension of all of this. There is much of expectation here, and I can also feel some level of anger and frustration.
When I see how long nothing happened, I can understand some of this. But please also understand me, I'm now about 2-3 weeks involved into this at all.


However, of course I have ideas, and I even heard the usual "stop here"-comments, because I sometimes tend to "revolutionize" too much ;-)
I have the following three concrete ideas:
1. Increase the number of formulas and params for formulas. I have spoken about this with our formula-inventor Luca, and he had some good arguments for this.
2. Create more bokeh options (this is my own idea I have not spoken about with others, yet)
3. Create an interface, where users can create formulas (without much coding involved, especially not ASM). From my experience users love such an ability a lot. And I heard already many voices, that this would be even more true for MB3D.

An additional, yet vague idea, is to create a new interface, as this is my primary strength. But, I know that many people like the current interface, so I'm thinking about a new optional interface (i. e. you can switch between new and classic). My goal would be to have anything related to design one single fractal into one window.

I also saw already some of the many feature-requests here, and think many, can be done. But two of them not:
 - true 64Bit version: very hard, because of the current code-base, probably needs a complete rewrite
 - GPU-renderer: does not really make sense in the current environment (Delphi/ASM). It would make more sense to rewrite from scratch, but then it would be even make more senso to contribute to Mandelbulber/Fragmentarium


Any further suggestions are welcome, of course.

Andreas

Sounds great Andreas, I second the request for a mutagen system

If that's the case, then why not contribute to Mandelbulber, or Fragmentarium? To me, it doesn't make a lot of sense to work on an unwieldy codebase that will need to be scrapped or rewritten at some point in the future anyway. Is the interface the main reason why people prefer MB3D to other programs? Because, if that's the case, then it may make more sense in the long run to create an all-new "clone"of MB3D, with a similar interface, and with optional GPU rendering to offer even faster speeds.

But the idea and concepts started as a short term project :)

@thargor all the best for your ambitious plans!

if you have a real concept for bringing in formula nodes or something, try that but i believe its harder than you might think, because the rendering pipeline is optimised for this, but perhaps you can implement an gpu rendering pipeline, but doing with delphi ... humm ... tricky i think ;)

in my eyes the approach of mandelbulber is the way to go, they already have implemented an gpu based distance estimation module, getting this to be importable by mb3d (because of the more intuitive hybridisation ) would be great but i think it would be more than a year of hard work

at the beggining i would suggest sticking to minor adjustments like more formulas, and a more intuitive formula order editor like one postet here, to be able to swap formulas instead of shifting would already be a great improvement

as well to include totally new formula types like pre-post transforms ;)

but whatever you do do it with fun! i personally underestimated how big the mandelbulb3d crowd is today, we had like 3000 direct downloads on a single day when luca posted the last formula collection with mb3d

Very nice to hear your challenging plans Andreas! Hats off to you for picking up the development of M3D!! I hope you will not be discouraged by some of the, in my view totally uncalled for, comments from some forum members and will be able to put your ideas to work. I'm sure to silent majority supports your efforts completely and will embrace every new version you will produce! I know I will  ;D

I love the idea of adding bokeh. Maybe you can also have a look at increasing the "reality-feel" of the FOV settings? If it's not asking too much...  :embarrass: Everything in your own time of course  :dink:

Thank you for picking this up Andreas!

Good idea. switching back and forth all the time between the main window and the navi would make the workflow much easier.

The "3D Navi" (Navigator) has evolved over time to add numerous controls.
People still keep asking to add this or that extra item to the "Navi".
It actually makes more sense for the Navigator to be the main interface with all the controls except Post Processing.
Like the current Monte Carlo render window, the Render would be in a second window or tab containing the Post Processing controls as well as duplicate Lighting controls .

One thing to keep in mind is the ability for the user to resize the real time Navigator screen smaller for slower/older computers.

Also, I would like to see Mandelbulb 3D kept fully portable without external dependencies.
Do you think this will be possible or will you be using Java Runtime?

5 cents ;)

a quick google returns some REALLY interesting things that may be...

...of interest...
http://www.clootie.ru/Projects/nvidia_cg.html

...important?...
https://code.google.com/p/delphi-shader/

Mutation generation may be interesting, hate the idea of changing the UIF though but if it's selectable guess it's OK. The UIF, speed of render and the Navigator are the big drawing points for MB3d, the convoluted UIF on Bulber and no Navigator not to mention the Render speed are the reasons it never took off like MB3D.  Developing my own formulas are of no interest to me but I know a lot of people would like to which is fine to have that capability. I was thinking a couple of more Lights available would be useful sometimes and maybe a scaler on the Lightmap function like there is on the Surface Map, just a thought.....also in DE Combinate Mode the capability of combining 2 Hybrids instead only one formula with a Hybrid also in DE Combinate Mode adding a couple more formula slots for that Mode. In the Post Processing there is the option of calculating Transparency on d.IFS components only, that option would be extremely handy to have on Reflections also, that's one option I would dearly love to see. These are just my thoughts off the top of my head anything you come up with Andreas we all will be glad to try and be happy for.

You can do that already. In DE Combinate mode you have a counter that appears and allows to select at which slot starts the 2nd hybrid.

I thought that only designated where the calculations for the second part of the Combinate started you can still only have one formula in Part one not a 3 formula Hybrid and another 3 formula hybrid....or have I been looking at that wrong all this time......

This (the first) is also my plan, but I think I will utilize a (free) library which offers more/improved UI-controls.
Java will not be involved at all.

Try that!
Mandelbulb3Dv18{
g.....S....O/...w....2....UI8bZW0Fw..vflouuR5q1Enkzd96a2YwXP7ms3oA8xzKslPr8Q.WzD
........................................kz1........Y./..................y.2...wD
...Uz6....U0..../MU//.....kq....K/....E3.....omEQgisq6rD/..........m/dkpXm1....U
z.....kD12../..........wz.................................U0.....y1...sD...../..
.z1...sDolFZd9iBmx1..........KzJxr2fLrdjgAZeBnNCHuHP4fJZymxOzslPySyorRqDPaV0iHmo
KuHDcNPuHTrNzayP2AdjQjqDU.....Y6..............sD.6....sD..G.....................
.............oAnAt1...sD....z...........................................8....k1.
.....Ksulz1.......kz.wzzz1.U..6.P....U5...EB....m....c3....F....6/...I1.....SF52
...U.qFG9yzb2zzzRYoWzz7lz16.pc..zXCc..kvrEtMc7xD6ocyFE0ujz1..........2.28.kFrA0.
.Ub96aAIVz9.1se7Umvxz0........../EU0.wzzz1...........s/...................E.2c..
zzzz.............0...................2./8.kzzzD............8....................
/EU0.wzzz1...................................2CcN/UvNPcveeWCNq0.yRiibHJJUk1f..XR
SvBmx3CcN/UvNPcvQsLsUa3.ibhVi1bTV1OK.sSq4uCly3CcN/UvNPcvMwLsUa3.ibhVinqTV1OK.sSq
4uCkz3CcN/UvNPcv..EsUa3feeWCNqGQIJ36wk8EwyLsUa3f................................
E6...EE.m6E..........6....EGiFLNbJaQU.pPrJaQ.........................c..........
...................6./........zj................................................
................................................................................
.....................2.....3....8....AJOZ75QdtqQfZqA............................
.....MU/4MU/4..................E........kz1........wz.........zD................
................................................................................
................................/....E/....0....TFZQVtqQaxaQh/..................
................3IE/0MU/A...............ozXaNaNaNaNwz0..........................
...................................wz...........................................
..........................................E.....I....c....EHZtqNZ7rA............
..........................U/4MU/4M.1...............0./........zD........kz1.....
...wz...........................................................................
........................................................}
{Titel: main paras~}

Yep your right I was just doing some experimenting too and it works. Don't know how I misinterpreted that all this time...I'd blame old age but it's more than likely the Weed... opens a whole new area for me, okiedoke scratch that it always has been able to do that...Thanks bib I appreciate that

Any idea of the speed reduction using non ASM formulas?
Wouldn't this also affect the real time navigator?

Parameters that use custom formulas should have a new/different format so they can be shared easily.
Would it be possible to have a plain text parameter (maybe xml = ".m3px") that included the custom formulas?

I would love to be able to search inside a folder of saved parameters for a specific formula or text string.

This is very hard to predict, the idea is to (pre)compile the formulas. But I did not chose the concrete technology to do this, yet. I will probalby later evaluate some things, and discuss/show the results to make a decision (if there are multiple alternatives to chose from).

I think this is really an awesome idea and can be developed without too much impact on the other parts of the program. So, maybe, this is also an excellent "warm-up"-addition, I will think about it :-)

I'd like to try and get it to work with OpenCL  :beer:

I know Gnofract4D does pre-compile 2D formulas, you can even edit the source text in the same window as the fractals are rendered:

(http://i.imgur.com/er28wfs.png)

It's open source, so you can look at the method to evaluate.

Looks like a great tip!

writing a compiler ? uh, that is a quite demanding task and is not done in a single coding session, but if you like ;)

No, but Andreas wanted to :)

That 's a really good news..(further developpement..)

My opinion and wishes.

-keep the actual interface.(my opinion)
- possibility to create some formula is a great feature.
-A second texture slot (one for classic formula, and one for Difs ?), mainly having a different texture for the heigmapdifs will be great.
-A water plane like in mandelbulber.
-possibility to import external gradient. (gradient from apophysis for example..)
- A Possibilty to export 3D object like .obj.  That would be really great !

I probably much reason in artistic way possibility than technical ability.

In any way, thanx to all who works to this project.
philippe

Well, water plane is very similar to gnarly1,2,3 ifs but with more controls.
I don't know if it would be so useful to add another gnarl-type plane?
I am also evaluating to create faster version of gnarlies using (good at 10^-5) approximations instead of slow sines. ;)
To do this I need to replace 'fsin' instructions with a 'call', and also add some constants. Not that long but still time consuming!

Already there!

It's convoluted and requires other software, but MB3D can make a Voxel Stack which can be converted to an obj file.

There are quite a few threads on this topic if you want to see how it's done with examples.

The obj files can be huge and cumbersome  (huger and more cumbersome with more detail!), but worth it if you use 3D Software.

Working the voxel stack through Fiji is possible but not very intuitive. There's a STL export feature in Incendia that simplifies the workflow significantly and offers some settings like size, thickness, algorithm type (cubes, Gaussian...), so why not in M3D? :D

http://lab4.fme.vutbr.cz/heatlab/OpenCLforDelphi.html ?

Jeremie, in my opinion it's a very hard work as you need to do some complicated 3d matrix postwork with convolutions or similar black magic. :(
I think it's best to do tiny steps but sure ones :)

My two cents:

1)  Andreas, GO FOR IT!  Whether you do a re-write, or an extension, have at it! :D
2)  UI:  Whatever changes get made there, the end result should not be worse than the current.
3)  UI:  Resizable NAVI - Yes!  If you go to a single window preview/render solution, then resizing should automagically take care of itself.  I see why there were two windows - one to render, and one for the Navi.  And with regard to the Navi, I am not overly fond that it doesn't quite show what the render will (even at reduced pixels).  I do understand why it works that way, just not fond of it.  Don't get me wrong, I'm not displeased either.
4)  Formulas:  Having some way to swap formulas in/out (and around) without losing a previous configuration (without doing a lot of file saving/reloading of trial parameter sets) would be great.  For example, I've got three formulas going in the set, I like the Render/Navi result, but I want to try "this" without it being added to the parameter set unless I like the result.  Think "scratchpad."  If the Navi could do that...  If that makes sense...
5)  I would love a GPU render.  Processors can't be swapped out like graphics cards can... ;)
6)  Formula creation:  I'm nowhere near that, but, perhaps some day I could be if I could be taught the math behind it all (and that's a huge challenge).
7)  I'm a visually-oriented person, so, anything that makes the interface work a little more visually is a good thing for me! :)  This is why I like MB3D over most anything else!
8)  Lighting:  I don't see why this couldn't be an open-ended thing; in other words, why the 6 light limitation. 
8a) Lighting:  Spotlights!
8b) Lighting/DoF:  Currently the DoF function doesn't play well with the lighting at times (blurs the lighting, especially volumetric) - that really needs fixing.
9)  Formulas:  As with lighting, I don't see why this needs to be limited to 6 either.  But that's really not a big deal, and probably overkill to go beyond that number - but it could happen! ;)

I like the idea of Bokeh and better DoF (maybe add some blur types - Iris, Field, Tilt Shift). :)

Otherwise, I will take whatever "you all" eventually create (beggars can't be choosers)! :)

Thanks for taking this on!

First of all, many thanks for taking this on! I got into Mb3d after development stopped, so I've done all my learning with the current interface, but here are a few things I'd like to see, if we're doing wishlists:

1) Rule-of-three guidelines (optional) in the Navi, to help with composition.

2) It would be great if the diffuse-color-from-map option affected the Navi as well as the main window, but I suspect that would be trickier.

3) Import/export of gradients from other programs would be nice too, but I think someone else already mentioned that one.

4) Easier browsing for color maps and backgrounds, perhaps not limited to a pre-set directory. I guess the problem there is that you don't want to be giving away a map of your hard drive organization with the params ...

About some planned new features (such as export to .obj, rendering on gpu, etc.) - may it be release this as external console utilites?
One of prefer this way is not crash the main tool - Mandelbulb 3d.

At least the geometry-export will probably implemented as external tool (which is transparently called from the main app), because this way it could be used also from other software and it would be easier to create a 64bit-version, which may be necessary for huge meshes.

haha, and my 5 cents for features:

please include a layering mechanism, it should be doable to separate the formula definition and define multiple formulas to combine really different 3dfracts together, along with the reflection and MC (monte carlo rendering) it is opening up huge possibilities!  :angel1:

Sounds interesting, but could you please explain this more, grouping/layering of formulas I understand, but what do you mean with the reference to reflection and MC? That this could create visually appealling images, especially when relection or the MC-renderer is used?

Andreas

in another thread a user wanted to place a jerusalem cube above a mandelbox and show it only through reflection in the surface ( or something ;) ) which would not be possible without a layering mechanism, the MC reference was just my excitement, realistic looking images with parametrized positioning/creation of the scene contents to create scenes like descripted in the begining of this post are not possible right now ... as far as i know

Okay, got it :-)

It is possible to do today with de-combinate, here is an early example of my own:

(http://nocache-nocookies.digitalgott.com/gallery/9/thumb_1002_14_01_12_1_50_16.jpeg) (http://www.fractalforums.com/index.php?action=gallery;sa=view;id=9921)

(or do I misunderstand you Christian? )

Here are the example parameters I posted in the other thread Christian mentioned.

Sorry C, but it sounds like something which has been there for quite a while ;)

Mandelbulb3Dv18{
g....kG....Y/...w....2....kozRIb5ZcB.1cYCgnAfT3ET75LgOFuTwfDRexvPhIvzeXZQK//uBzj
................................gkda61E/Ez1........Y.d..................y.2...wD
...Uz6....E0..../M.0/.....Uu....S0....E3.....waApu1VPotD/..........m/dkpXm1.OaNa
y.....kD12../..........wz.................................U0.....y1...sD...../..
.z1...sDYt/FwEs4Ry1..........KT5Ya2GMTgjlRaIqnB13vXz03vLgWpWzIUhzYvAmatDP5S9PCjN
quXp5Sqin6Pazq8.ap3fMhsDU.....I1..............sD.6....sD..G.....................
.............oAnAt1...sD....zw1.........................................J....k1.
.....Ksulz1.......kz.wzzz1.U..6.P....M2...EB....m....c3....F....6/...I1.....SF52
...U.W1KEyzlciszsU3YzTAe906.oc..zzSi...MarH7iXyD6oa4dabdnz1..........2.28.kFrA0.
.Ub96aAIVz9.1se7Umvxz0........../EU0.wzzz1...........s/...................E.2c..
zzzz.............0...................2./8.kzzzD............8....................
/EU0.wzzz1....................................8cU0.E./2Ezz/cU08../2E.tzDU08c..2E
./IzT/8cU0.E./2EQs5cU08../2E./bTU08c..2E./2ly/8cU0.E./2EMw5cU08../2E.lqTU08c..2E
./2kz/8cU0.E./2E...cU08czz/cU08cyz1cU08cxz3cU08c................................
E6...A..V6E.....2....A....EEh3aSdtqNU6oPs/UQ..........................k/9.......
...................../........yD........kz1.....................................
................................................................................
.....................2.....3....6....w3Jm3aPnlKMoJqEoE4.........................
........................................h.2.......U4./..........................
................................................................................
................................/....E/....0....8BIRWJqA........................
..........U3....................ux7QLabUOz1...................zD........kz1.....
...wz.........zD........kz1........0./..........................................
............................................}
{Titel: main paras~}

...so an extention of the DE.combinate is what we are looking for I assume...  O0

However, more formula tabs and possibility to de-combinate several hybrids would be great... Maybe that is what you meant?  O0

oh, i see, yes but separation to separated independent formulas would be more comfortable :D especially because you cant combine everything with de combinate (or i am wron!? ) and you are not as free to combine anything, because: de combinate allows just to recombinate base-formulas, but not multiple hybrids in a single image ;)

You are wrong ;) you can mix two hybrids, you can decide to make the "mix" between f.ex formula 1-3 and 4-6 or 1-2 and 3-6. I can post an example later...
...or you could read the read me file in m3d ;)
But you can only mix two hybrids (or base formulas).
I can't see the difference in this way and the one you try to describe...

yeah, my approach just gives more intuitive creation, and more possibilities (e.g. 10 mboxes) and furthermore when separating the formula definitions completely from eachother for a layer, different colors for each would be possible as well, right now it seems to work as you describe, but hides some obvious possibilities (limit to 5 hybrid formulas, global color set up )

OK, I get it. Possibility to have seperate colors wood be awesome! Good thinking C! :)

Actually, you can manipulate color somewhat by changing the number of iterations per hybrid. If you do this right, you can use one part of the palette for one hybrid and one part for the other. But your discussion provoked another thought: It would be perfect if you could assign different maps to the separate hybrids!  ;D. Would that be feasible Andreas?

just dont even think about making such workarounds possible, it would all be gone if a single "hybrid formula" can live happily side by side with many others

Really need to check this in more detail later (and also the code) to be able to give a stressabe answer. But I think I have understand the problem, or at least the major part of it :-)

I am so happy to read of continued development of MB3D :joy: :love: :thanks1:

I wouldn't focus on complete refactoring. Fixing easy to fix bug, slight improvements would be a great start.
Two ideas:
1. A quite simple but really helpful feature for setting values:
select a slider whose value you want ot change (for instance X-pos of a positional light)
press a hotkey (ie 'v' for value).
a small window opens and shows the numeric value of the slider.
you can now change the value on a numeric basis.
this would be in some situation be more accurate, when the smallest movement of the slider is still too big (I had this situation various times).

2. A pure XML-Export of the parameters could open new possibilities for automation. For instance you could create flights via scripts by setting the camera position to the wanted position or let positional lights move at a perfect sinus wave. The actual format is great for sharing but an extra more open format would be cool.

A formula editor would be also very cool. But I think this is a bigger project and good performance maybe hard to reach.

Resizable navigator - also yeah.

Thumbs up to all who help to keep Mandelbulb 3D alive.
Andreas, hit the keys  :dink:

Thanks!

I'm currently working on enhancing the formula-window to show changes you make on parameters and combinations on formulas automatically, and to make the window resizable, and finally increase the numbers of possible formulas of 8. Sounds not to be a big step, but the latter causes a huge number of changes, and requires new revisions for all file-formats involved, and will require a lot of testing. (Increasing the number further would need even more changes (types of certain properties has to change), but I dont want too many changes at once, because of stability reasons.

I think an XML-format would be excellent at all. Maybe even as replacement of the current *.m3p-format. It would be too large for sharing params at dA, so the current "clipboard-format" has to remain.

Andreas

Regarding xml... and copy paste sharing... like i told in another thread, zip compresdion and base 64 encoding is the way to go, when compressing redundancy might not be an issue, but going straight for a json format wouldnt be wrong as well because the information density would be more compact... judt my five cents very nice to hear that you are already able to compile (what ide are you using for that ??? ) and digged into it already, getting familar to the inner structure obviously takes long time

fiddling with formula amounts might already be a too big step...

I think would prefer XML as there are many tools which help you create/edit such files with syntax check/highlighting.
For compression: does anybody know what is the size-limit of params in order to exchange them via deviantArt or Facebook?

I'm currently using Delphi XE6 for compiling.

There's a 64K limit on text-based submissions to DA, which I guess would apply to the text that goes with an image as well. If you submit as a zipped file you can go up to 200Mb. I find it hard to imagine even the 64K being a problem for parameter sharing -- a more practical limit would be that it's a pain to copy-paste more than a couple of screens at a  time, though I have seen people post quite long flame params. It looks as though the limit on Facebook posts is just under 64K: https://www.facebook.com/schrep/posts/203969696349811

I think this is fine and much enough, thanks for the info!

As XML is quite verbose, I think it's worth minimizing the size for convenience. I find that zip plus base64 encoding cuts size of my text plus numbers parameters to about a third of the original size.

Agree, the current idea is to make an XML-format, but save it somewhat compressed.

Maybe to make it even to a container-format (like OpenOffice-formats), allowing to include additional data (e. g. maps).

Any chance of including the formulas themselves as assembly code so parameters with custom formulas can be easily shared?

Just an update: I will approximately need another 1-2 weeks to finish the new major JWildfire-release, then I will come back to MB3D to work on the new release

Andreas, i like the new v190, even though i'm using the FinalBeta version, i have no complaints whatsoever, you've done a bang up job implementing the Muta-Generator, and being able to change the interface is outstanding, which i think is great, i think sometimes ppl go way beyond what MB3D is capable of performing, to me everything is simple and when you try to push the envelope that's when the crashes happen! Much applause Andreas to your valiant effort! :cantor_dance: :cantor_dance: :joy: : :D

Thanks for the encouraging words! Not many crashes were reported yet, but I can imagine that people are complaining a lot about them at their social platforms.
Indeed, crashes sometimes also occur at my side when chosing certain formulas. Also the JIT-formulas sometimes can cause strange behaviour.
This is not really satisfying, but difficult to solve, and probably not completely avoidable at all, without a rewrite of essential parts of the program.


Best regards,
Andreas