The biggest issue with plain layer offsets is parallax won't work with them.

It may have to be parallax, or offset for all layers, not both, and probably not alternating either.

That's not true, they can work together. Imagine that the offset is an independent parameter that maps to the amount that the layer offsets from the scroll position, like: "layerPosition = layerScrollPosition + layerOffset". One can then have the layers move with scroll plus control the layer offset, or can alternatively set the scroll rate to 0 and move only with the offset without being affected by scroll.

The only thing is that the offsets need to be taken into consideration for the collision cells like Ashley mentioned. Apart from that it seems quite trivial to implement.

I felt the need for this feature sometimes in the past. Although it's not something I'm really in need for C2 right now, I really wish to see this in C3 as it would be very handy.

Ashley

I'm not sure how you are implementing things, but maybe these links may be of some utility to you (if you haven't found them on your own):

http://hacksoflife.blogspot.com.br/2010/02/alpha-blending-back-to-front-front-to.html

https://developer.nvidia.com/content/transparency-or-translucency-rendering

That's great to know.

I've done some research about front-to-back rendering some time ago and found a site that described that it's actually possible to use some special blending modes to make front-to-back rendering feasible even for textures with alpha.

My guess is that if something like that was implemented in C2 it would have a limitation on how effects could be applied. But maybe it's possible to have a mixed system that process the objects inside each layer front-to-back but compose the layers back-to-front, so you can apply effects to layers. Not sure if the performance gains would be significant in most cases though.

Perhaps it's possible to pre-detect the objects that interact with other objects that contain effects and render them first back-to-front, then render the remaining objects front-to-back blending them with the previous result by using a depth test.

—

I believe it's like using a marquee or lasso tool to pickup a portion of tiles placed on the layout, so you are able to move or stamp it in other places of the layout saving a lot of time. If you build a tree out of multiple tiles with different branches and stuff you could clone it in the layout without having to reconstruct it from scratch every time. Like a brush made from a collection of tiles you pickup from the layout.

Its still extra overhead, and the string manipulation would be even slower than an if. Whats the issue with separate actions? Its essentially the same.

Q3DMaster is the most complex C2 plugin I have ever used, and I must say that it takes a lot of time to navigate among all those actions and find what you need. Particularly, I wouldn't mind to trade some micro optimizations for an easier to read event list. It would also make easier to refactor those events and quickly test different transform spaces. It may not seem like much, but when you can't count on the editor and have to do a lot through events, testing things all the time, every little speed up in development counts.

The switch statement for the dropdown would make the set position action very slightly slower per call, but the fact set position is so common made me do it that way, because it becomes a waste if you start having thousands of set positions per frame (which is pretty expected in larger projects).

I'm not much into C2 plugin development, but can't you avoid the switch by calling different functions and get less overhead?

Like:

On setPosition action
-callFunction( "setPosition" & dropdownIndex )

On Function "setPosition0"
-do transform in world space...

On Function "setPosition1"
-do transform in local space...

On Function "setPosition2"
-do transform in parent space...
[/code:3puo84z7]

—

I tested on a MotoX 2013 (Kitkat), a MotoG 2014 (Lollipop) and a Galaxy S4 (Lollipop) and all worked really well on Chrome when exported for web (with minify script off). I use the MotoX for preview over wifi and never had a problem. I haven't tested exporting with Crosswalk yet, but I'm planning to do soon.

QuaziGNRLnose

I don't know if you have considered, but I have a suggestion to merge similar actions to make the plugins simpler. For example, there's three different "Set Position" actions, one for each coordinate space with the exact same parameters. They could all be merged into one that have a dropdown parameter to select the transform space. The same could be done for "Look At" and "Rotate Around" actions. The "Translate" action could also benefit from a dropdown to select different transform spaces.

*It seems a bit inconsistent that in Q3DModels and secondary plugins it's called "Translate (local space)" and in the Q3DMaster it's called "Move along local vector". They do essentially the same thing and could have the same name for consistency.

So I tried to follow your suggestions and had a hard time making it work with a plane. A cube worked flawlessly but not a plane.

In the end I was able to solve it and discovered a bug. Technically is not a bug, but it's an unexpected behavior that could be improved.

Here's a capx that demonstrates the problem: q3d-fit-bug-A01.capx

• Try to run the preview. You will see the cube textured rotating as expected.
• Then enable the create plane event, disable the create cube and preview again. The plane will not show up.

To make it work you need to change the Model Fit to Fit X or Y. Apparently it tries to fit the Z of the plane that technically has no Z dimension.

It would be better if the Model Fit "Fit" ignored the Z of flat geometries like planes and circles, so it doesn't disappear unexpectedly.