Does anyone know if it's possible to have particles inherit the parent Particles object's motion?

I've been looking for a way to do this, but can't seem to find a way besides spawning Sprites instead of built-in particles and doing Event Sheet logic - which kills the performance advantage of using built-in particles...

Alternatively, can this be relatively painlessly added as a feature? Possibly with an inheritance percentage instead of a on/off bool? I can see many cases where users would want particles that stick relatively to the emitter...

Thank you in advance for any suggestions.

@lucid

A feature request, if feasible: with the Vanishing Point feature introduced to C3, allowing for skewing the camera viewing angle, every Sprite or "flat" object (like Spriter) is locked to being aligned to the Z-axis, while sometimes, you'd like to align it to the view axis instead (hope I'm making sense).

Would it be possible to either:

-add Mesh Distortion to Spriter, so one can make a "vertical sprite" by moving vertices

or:

-allow the 3d Object to pick the texture from Spriter - this may need official support, right?

Sigh, I really miss a general-purpose texture sharing plugin like TextureSetter from Construct Classic.

Again, thank you for the great work on the plugin.

That's a well-rounded feature set you have in mind.

My 5 cents:

-at least for my use cases, dynamically changing the triangle count in a mesh is not a high priority function - like you wrote, replacing the mesh source while keeping other visual properties the same achieves the same functionality.

-for a simple animation system, I would suggest the way Element3d does it (an After Effects plugin) - it reads and plays back .obj sequences at a chosen rate - if it detects the same number of vertices between subsequent frames, it smoothly blends the transition. If not, it simply snaps to the next frame when the time comes.

For something more advanced, reading a frame order sequence from a variable or Array would be great too - simple animation trees could be built with this.

-for 3d math, I totally agree - parenting would be great, but then, ideally, shorthands for space translations would be needed (parent->world etc.), not to clutter the Event Sheet...

-lighting/shadows would be great - I'm assuming some form of Shadow Mapping? I would suggest adding a hemisphere light like the one in three.js (https://threejs.org/docs/#api/en/lights/HemisphereLight) - it alternates between two colors based on surface normal orientation to the light object. Good for old-school, retro effects.

I think that's it for my wall of text. Again, thank you for developing this.

Very nice! Much appreciated.

When I saw the per-vertex creation mode, I knew an .obj loader was either already in or on your mind...

Feature-wise, I'd like to request:

-ability to change texture filtering mode as grossrob0 suggested - at least unfiltered and bilinear would be great.

-ability to either take textures from a Construct 2 Sprite or to have the ability for the Triangle3d object to hold images/Animations like a Sprite, with an additional option to load texture from URL (like the one available in the current version)

-ability to have separate front/back textures for faces (for low-poly/stylized stuff)

-mesh animation support, either via .obj sequences or moving vertices via the event sheet... I understand continuously loading .objs may have a performance impact...

-support for .md3 (Quake 3 model format) - it's an old format, but there are exporters for modern DCCs for it, and it supports vertex animation.

-basic per-tri raycasting support. if it's unfeasible, per bounding box will be good.

Anyway, these are just my wishes - again, thank you for the plugin - even in its current version, it's a stable .obj loader with proper depth handling - for which I already have plenty of use.

A small-ish request I figured I'd post here: would it be possible to add a "color" option to the Scml object, to uniformly tint it - like the Sprite object? Thank you.

R0J0hound

Yes - works perfectly. Thank you.

Quazi:

Two quick questions:

-how can I mask the reflection map? For example, making windows more reflective and the wall less, in a building facade texture

-how can I add an emissive (self-illuminated) map?

R0J0hound

Is there a layout size above which Chipmunk stars loosing precision/becomes unstable? I managed to find this thread:

https://chipmunk-physics.net/forum/view ... f=1&t=2771

which states that Chipmunk uses double precision, so layouts of around 100K in size should still be fine, right?

Actually, top left is (0,1) and bottom right is (1,0) - you can check it by visualizing the UV coords - something like:

output = vec4(vTex.x,vTex.y, 0.,1.);

I was confused about that as well - most sources say (0,0) and (1,1).

Update 24/07:

Do re-download the effect. The only change is that the effect parameters do not start with a number anymore. Apparently, if a parameter name starts with a number, Construct will read the .capx with the effect as "corrupted"...

If you have saved a .capx with the older version of the effect and Construct refuses to open it, do the following:

• Leave the error message open
• Rename the .capx to .zip
• Open the .zip
• Find the file referenced by the error message
• Open it in Notepad or your XML editor of choice
• Go the the line referenced by the error message - you'll find that these are the effect parameters' names.
• Change the names, removing the number, fullstop and space at the beginning. ex. "1. "
• Re-save the layout file, rename the .zip back to .capx - it will open properly now.

Apologies for this - as far as I can see on the forums/help files, the parameter name issue is not documented anywhere...

The numbers are now in the parameter description - their purpose is to let the user know which property has which parameter number - for control via events.

Gradient Map

http://s000.tinyupload.com/?file_id=724 ... 1666677795 <- URGENT UPDATE. SEE BELOW POST FOR INFO

Works like Gradient Map in Adobe Photoshop ( http://media.tumblr.com/tumblr_m66m4yiOs91roapsd.jpg) - it's only a six-flag gradient, because the UI gets exponentially longer the more flags there are. No limitations of this one, except one: the flag positions must be in ascending order, otherwise the out-of-order flags will be ignored.

The parameters are numbered, so it's easier to know which parameter is which in the Event Sheet.

Source - specifies the source of the colors to be remaped - 0 is the sprite itself, 1 are the pixels under it.

Intensity - a uniform blend between original colors and remapped colors.

FlagX R, FlagX G, FlagX B - color values for the given flag.

FlagX Position - position of the flag. 0 is far left, 100 is far right. Flag0 is on the far left and Flag5 is on far right. Remember, flags 1 to 4 must be in ascending order otherwise the out-of-order flags will be ignored.

Enjoy.