Chad's first impressions and initial confusions

Deprecated Ember Discussions
1

Ok, this is totally mindblowing, really reminds me of when we first started using Krakatoa and we just knew there was a huge amount of potential if we could just wrap our heads around it.

I know I’m supposed to show cool stuff first, but I’m really confused and need to get some things off my chest as a first time user and probably need to be corrected on some of my assumptions…

  1. Darcy said “When scrubbing the time slider, the object will run its “per-step” expressions in a loop until it reaches the Max slider time. Currently the simulation is not reset when scrubbing backwards. It is only reset when the slider is positioned at the beginning time (hard-coded to frame 0 at the moment) so any changes to the expression or object’s parameters will not be seen by the simulation until resetting the timeslider.” But I’m seeing any changes to the Initial State MagmaFlow only update when the time changes. So I have to go from 0 to 1 and back to 0 to see it do anything.

  2. The SIM Ember macroscript tries to set Divergence Free on the object it’s creating, but that input doesn’t exist. I commented it out, so we’re good, but I’m wondering… Should the Input Value 1.0 -> Output Density not just be the default anyway?

  3. Picking the Sim Ember is really hard. You have to select the logo. Could there be a bounding box we could click on?

  4. So every SIM Ember is history dependent? And every PRT Ember is history independent? And SIM Ember only makes fields and PRT Ember only makes points? So we can’t make a history independent field or history dependent points? Just making a little 2x2 table here to compare and hoping I’m getting it right.

  5. For customers who have Genome or Krakatoa, if we buy Ember, will we get the Ember category in PRT Magmaflow and VFC Magmaflow? (I just made VFC up, we’re now getting REALLY confused as to what Magmaflow context we’re in).

  6. You can Output Position from SIM Ember. Either that’s a bug or I’m really confused. What does this do? I was thinking maybe I could store the position on the grid, then advect that and then I could get a vector between the Input Position and the Position Channel, but InputField won’t let me get Position. Output Position for PRT Ember makes sense to me, but when I use it the points disappear.

6b) Speaking of InputField, if you add Outputs to a SIM Ember, the InputField in other Ember objects doesn’t show those new channels.

  1. Can you set the SIM Ember display channels to None? I don’t want to look at vectors anymore.

  2. SIM Ember (Initial State at least) doesn’t show viewport displays if one of the outputs is disabled. I have to delete the output.

  3. Can PRT Ember operate like PRT Volume and have a sampling resolution where the MagmaFlow is run and another resolution where the points are interpolated from those samples? Like I want to get 40M points, but only run 1M samples and just interpolate those results?

  4. The SIM Ember magmaflows don’t filter the active SIM Ember from the InputField selection. Not sure if that’s possible or not.

I’m going back to making stuff now, I’ll update with either more questions or some results. :slight_smile:

2

Yeah that is a bug. I’ve been noticing the same thing. I really think it needs to tell me when what my settings are showing don’t reflect the cached simulation too.

I removed that property at the last second replaced it with the None solver. Forgot to try the macroscript :frowning:

Absolutely.

In order to generate particles in a time dependent manner, we want you to make a PRT Ember object and sample the Sim Ember via an InputField node. This could be made as simple as one click to have it done. I like keeping the history dependence isolated into the Sim Ember.

We have plans for a history dependent particle object that fits into this ecosystem as well. For the alpha release we felt that PFlow + Ember Follow would suffice.

The history-independent field idea (w/o the particles) seems to come up enough that I might allow PRT Ember objects to be pickable wherever a field is needed. I originally wanted it to be the bridge from Field to PRT but its probably too redundant to have a separate Ember object for procedural fields that aren’t converted to particles.

The Ember category nodes will be specific to Ember (except the InputField node which will be moved out and become the glue between Ember and other packages).

Totally a bug. The Position channel is implicit and should never be written to. Even in a PRT Ember the position of the particles is implied by the seeding algorithm that happens separate from the Ember field expression.

That’s a bug.

That has been requested by Bobo already. The edit box is editable (sigh) so you can actually clear it manually to stop the vector display.

Sounds like a bug!

That’s not a terrible idea. My initial strategy for this was to have the user make a Grid node with an alternate spacing inside the expression right before the Output node. That would end with the same effect.

I’ll post it to our dev board and see if anything can be done about it.

Thanks for the feedback!

3

Here is the shocker - for about a week, I felt the same way :smiley:
We have definitely a way to go in the usability department, but this is probably also the first time you get a product so early in the development (mainly because it reuses existing UI code, so we could get there faster). But we plan to improve and simplify a lot in the Alpha and Beta process.
The first step was to rename all Ember operators to simpler terminology, e.g. DivergenceFreeCache is now SimpleFluid… :wink:

The Initial Flow is updated on frame 0. So you have to go back to it each time you make changes to the sim.
You can then step forward or play back the scene with Real Time off and it will advance by the time step (which defaults to 1, but if you set it to 5, it will do 5 updates per frame).
This runs the second (Simulation) flow but not the Initial flow. This is very similar to how TP updates only forward and you have to go back to the beginning to reset and start fresh.

My bad, I forgot to update the script in Subversion. Attached is my version. It sets Density to 0.0 for SIM, since you don’t want Density everywhere by default.
Ember_Creator_20120719.zip (1.22 KB)

The icon scales automatically with the bounding box which is kind of cool, but I think it should have a size scale factor so you could make it larger. Drawing a bbox would be useful indeed, like in a PRT Loader, without the grid.

Yes and yes. Yes and no. :slight_smile:
SIM Ember makes fields and can advect them by the Velocity field.
PRT Ember makes fields and can turn them into points for Krakatoa rendering.
You can make a History Independent field inside the PRT Ember.
You can make a History Dependent field in SIM Ember and convert it to point with a PRT Ember inputting from the SIM Ember.
LEGO!

Yes, Genome and Krakatoa Magma Modifier will have at least the InputField operator to read fields from SIM Ember.
Today, I posted a Genome+Ember example where I passed the data via a PRT Ember and ParticleSumRadius and it worked neatly:
youtube.com/watch?v=8d5_kmPX … e=youtu.be
So this will become much easier in the future.

I would say it is a bug, I just have to remove it from the list of default channels. You can write Position into any MappingN channel and advect that, then read it back. I actually advected a mapping channel and assigned to mesh vertices via Genome today and it worked too.
EDIT: FIXED INTERNALLY

They should show up. Make sure you initialize the channel in the Initial flow and set it to a value or to itself (e.g. Density->Density) in the Simulation flow if you want it advected. When you pick that SIM Ember in an InputField, the available channels should show up. Post an example if you can.

Just delete the name from the list (select+delete). We have a Wish List item logged against this for a or “” entry on the list.

Cannot reproduce. Steps or scene please?

Don’t think so, each particle is the result of a field sampling.

Should be possible, will look at it ASAP.
EDIT: FIXED INTERNALLY

4

Obviously not nearly as far along as Chad but me:

Number 7) Viewport display + None = Good, I don’t want to see this all the time either. or read below my thoughts on display

My stuff is all visual so far:

I like the way Fume handles grid display, IMO I would try to emulate its behaviour. It gives you the option to enable/disable the global display + individual channels (ember does this) BUT…

The toggle on the grid display on/off should turn on/off all viewport display.

A pin toggle (In Fume the + button next to the big display button) that locks the display on when not selected.

A slice would be nice. :slight_smile: The slice has all the point2 variations as well as grid position and thickness.

The bounding, as Chad had mentioned, is handy, if you can include the voxel/cell size in the corners that is a plus, Fume/Phoenix/Realflow all do this in their grids.

Displaying of numerical cell values is also helpful. (the optimize/reduce is very helpful here)

When I say exactly, it si relative, why not keep things uniform to existing or at least similar as possible to ease usability curve.

I understand the workflow of the Pflow Advection setup, to simplify, it begins with a seed (prt Ember), the sim runs (sim Ember), and pflow grabs with the follow.

Could you please post the Fume RF example? Little baffled here, I can sim the Fume and RF no need for caches of any sort.

5

I posted an explanation, I am sure you can set up your own scene and learn something in the process :wink:
viewtopic.php?f=149&t=7896&p=32801#p32801

6

Oh thanks, I suppose that is easier than reverse engineering it. It is debatable which way I learn more :smiley:

7

Oh I am sorry, I see what you mean by this! I just added an ouptut in the edit Sim and named it None and all is good. :wink:

My viewport ideas were simply observations, things I like about things that currently exist, you can take them or leave them, I just thought I would share.

Many confusions were cleared up by simply noticing the Ember node menu :blush:

8

For the history dependent objects, like SIM Ember, will we be able to solve them together, or will we be stuck with dependency loop issues?

9

Would it make sense for the macroscripts to make the SIM Ember/PRT Ember match the bounding box of any selected object? Like I have a teapot selected, it would set the domain to the bounds of that teapot?

10

IMHO it should match the grid size. That is how all grid based systems seem to be setup. Most of the things I mentioned a few posts up are directly related to either how Fume deals with vp visibility, phoenix or realflows grid systems.

11

Just hold SHIFT while clicking the Macro and it will match the current selection’s bounding box.

So,
No SHIFT - enters manual creation mode with click/drag to resize
SHIFT - if no object is selected, creates a default grid with 100x100x100 size
SHIFT - if one or more objects are selected, creates a grid that encloses them all

I think this was mentioned somewhere in the videos…

I also added a 3rd Macro late last night after the build was posted, will upload an update in the Builds folder. It is for creating Ember Force space warps.
If a SIM Ember already exists in the scene, the Ember Force will be set to use it. If two or more SIM Ember objects already exist and one of them is selected, that one will be assigned to the Ember Force.
The Ember Force also supports PRT Ember as the source, but I haven’t added support for that to the Macro yet…

12

Oh, nice. Guess it just needs the Shift part added to the tooltip. :slight_smile:

13

Fixed.
viewtopic.php?f=146&t=7914&p=32917#p32917

14

How cool is that! :slight_smile: