Posts made by Paul Everett

I think there is no access.

However, if you look at a group, you can see it is a point object. if you do CSTO on a group, you see that oyui get a polygon object with points. That has a bunch of channel vertex maps, and vertex color maps tags on it.

Float vertex maps are then for values, like lifetime.
Color Vertex maps are for anything requiring a vector such as angularvelocity.

not sure if these are just constructed when you hit csto, or if they are virtually present on a group(not tested)

the polygon object points, are the positions.

These maps can perhaps be used to interpret particles, but I don't see any way to create or change anything, or create any kind of modifiers specifically for them. it is a blank sheet. Let me know if you find anything useful

best
Paul

you can test for all cases, that's why I call those edges "candidates".

The devil is always in the details.

There are many ways to skin this cat.

best
Paul

Think edges. an edge has 2 polygons.

for each polygon, check the face normal direction against camera z vector. (dot product of normal and cam z)

run through all edges.

if the 2 polys of any edge, face in different directions, that's an outer edge candidate.
Build a list of outer edge candidates, sort it, and connect the dots.

more or less what Ferdinand wrote, but its simpler if you just think of it as edges.

best
Paul

1. you can sample a channel. it works perfectly for things like the layer shader.
2. if you really have to sample a shader specifically, what I do is make a clone of the shader per each context.

i.e. you have 16 cores, you make 16 clones, and insert them on the material and initing them, (being sure to clean up after)
Layer shader will then work as expected, off the bat, as long as you use the thread index to reference from your list of shader clones.
clones.shader_list[context.GetLocalThreadIndex()]

you also have to make sure you project your coordinate according to the texture tag. it wont do that for you.
p is always assumed to be a UV coordinate projected, as per the tex tag. you send p as a world coordinate with vd and if the shader needs that, that is where it would look. think of it from the perspective of a shader. where will it get a world position from? if you write a shader, and you need a world position for a hit, you look in vd for that. if vd is null, or the info has not been filled, how would it know where p is?

I found in most cases sampling a channel from a material rather than a specific shader, works best, and is less problematic.

best
Paul

@m_magalhaes said in DrawHUDText returns a white box instead of a text?:

TAG_IMPLEMENTS_DRAW_FUNCTION

I came across this problem today.

#define TAG_IMPLEMENTS_DRAW_FUNCTION (1 <<

note : you can add this flag to R21 builds, and your tags then display as expected in 22.

RE: DrawHUDText

z settings have no effect on text.
in 21, text is drawn behind poly objects.
in 22 text is drawn in front of obejcts.

IMO, this is a bit of a mess. the new draw flag should be the exact opposite to what it is, to keep compatibility.
small differences, make a big difference when your already bending over backwards trying not to have to rebuild everything yet again, for 22.

make sure the bitmap shader is not set to MIP mapping, then it works fine.