Page 1 of 1

Ops width for a better workflow

PostPosted: Sunday, 08.July 2012, 16:58
by erbsen
Hey,

I think these Ops need to be twice as wide to enhance the workflow.
It would be helpful if this could be implemented.

wz3 Bitmap: Merge, Distort.
wz4 Mesh: Displace, Add, SetMaterial.
wz4 RenderTree: Add, Debris, Sprites, Trails, FR063_Mandelbulbiso, Exploder.
New Wz4 Material: CustomMaterial, ModMaterial, SimpleMaterial, DoubleNormalMap.

3x Width:
wz3 Bitmap: Mask.
wz4 RenderTree: FR063_SpritesADF, ExplodeChunks.

Did i forget Ops?

Re: Ops width for a better workflow

PostPosted: Sunday, 08.July 2012, 17:24
by Skinnytorus
Maybe these (optionally):
2-x size:
wz3 Bitmap: Atlas (mostly used with more than one input)
wz4 Mesh: Retexturizer (always requires 2 inputs), Heal (2 meshes)
wz4 RenderTree: Marching Cubes, Debris, Add (part. node)
Wz4 Material: Add (green), Mul (green), Sub (green), Double Normal Map
Anyways, maybe it's better to somehow filter out the ops that have more than 1 input from the source code (wiki). Because if we forget some ops, we will lose conformity...

But the question is: will such default size be compatible with older files?

Re: Ops width for a better workflow

PostPosted: Sunday, 08.July 2012, 17:54
by ikam
But the question is: will such default size be compatible with older files?


yes you're right Skinnytorus I think changing default size will broke file compatibility.

Re: Ops width for a better workflow

PostPosted: Sunday, 08.July 2012, 18:37
by erbsen
Ahh, i haven´t thought about that, it should have been done much earlier.
Would you give it a try, then we are certain that it won´t work?

Re: Ops width for a better workflow

PostPosted: Sunday, 08.July 2012, 20:49
by reEto
yes it will broke file compatibility :) but erbsen, it is not so hard to reseize the used op.. harder would it be writing the code instead using a too small op :)

Re: Ops width for a better workflow

PostPosted: Monday, 09.July 2012, 08:19
by erbsen
Ok i get it, it´s not feasible, that puts it to an end.