About ts.TaichiClass about taichi_glsl HOT 3 OPEN

E.g., you have a Test class, which has a and b as 0-D field as components:

@ti.data_oriented
class TestClass:
  def __init__(self):
    self.a = ti.field(float, shape=())
    self.b = ti.field(float, shape=())

test = Test()
test.a[None]
test.b[None]

But this way your a and b can only be shape=(). Which prohibits you from having multiple TestClass.
So you may want to pass a shape as argument to its constructor:

@ti.data_oriented
class TestClass:
  def __init__(self, shape):
    self.a = ti.field(float, shape=shape)
    self.b = ti.field(float, shape=shape)

test = Test()
test.a[i]
test.b[i]

But this way you can only initialize it as global field, you can't use it as local variables:

tmp = test[i]  # ERROR!
tmp.a
tmp.b

You can't construct it as local variable:

tmp2 = TestClass(a, b)

You can't use a struct-for loop, or accessing its shape:

for i in test:
  ...

test.shape[0]

That's why I invent ts.TaichiClass, to utilize it:

class TestClass(ts.TaichiClass):
  def _init(self, shape=None):
    return ti.field(float, shape), ti.field(float, shape)

  @property
  def a(self): return self.entries[0]

  @property
  def b(self): return self.entries[1]


test = TestClass.field(shape=233)

as an walkaround.

In fact, ti.Vector and ti.Matrix are taichi-class too.

from taichi_glsl.

For your application case (the collider), if you have a lot of colliders, then using the method I mentioned in that post will be very low-efficient. You should use a Collider.field(shape=233) to allocate 233 colliders instead. Not sure if that's your case.

Could I directly replace every @ti.data_oriented decorator in a typical taichi class to ts.TaichiClass?

Not really, they're very different things.
Taichi-class only make sense when all its fields has exactly same shape. Which isn't the most common case.
Vectors are great examples for taichi-class, as it has 3 scalar field as compoment, with same shape.
That's why you can use vec[i].x instead of vec.x[i].

from taichi_glsl.

Ahh thanks for the detailed reply !

The truth is, after I saw your explanation, it seems I misunderstood the @ti.data_oriented. In the first place I simply regard it as a magic decorator, without which a Python class could not have a @ti.kerneldefined within.

Emmmm sry but let me have a second to reconsider this issue😂

from taichi_glsl.