twod
We try to remain as device-agnostic as possible by using OpenCL. Currently the denoiser is locked to Nvidia GPUs (as it's their denoiser), but we have plans to support other denoisers as well. As RobW mentioned, you should be able to run karma on both a GPU-less farm machine via CPU CL and a local workstation with GPU CL, without any user intervention. And if you're lucky enough to have farm machines with GPUs, you can use the GPU on both.
When the Karma GPU variant is released, of course

As far as I'm aware AMD has dropped the support of CPU CL. Does it mean that Karma would not work on AMD CPUs? Or maybe the third party OCL implementations like POCL would be a viable solution?

edward

hoknamahn
I totally agree. But this is the way wranglers work.

Ok, so I tried this and looked at the VEX code inside an Attribute Wrangler. So if the wranglers work this way, then I guess functions work within functions right now.

They do. But only if a value we return is not of array type. It's the case in both normal VEX and a wranglified one. So it's not a problem of wrangler's preprocessor as I initially thought. Looks like vcc needs more love

edward
I don't know. Personally, I hate functions within functions from my days of modifying badly written Pascal code.

I totally agree. But this is the way wranglers work. Plus their behaviour is not consistent nor intuitive (otherwise we would not see such questions).
On a contrary, we have a workaround

edward
void rgb_array(vector colors)
{
colors = { {1, 0, 0}, {0, 1, 0}, {0, 0, 1} };
}

vector c;
rgb_array©;
printf(“%f”, c);

Is there any chance that vcc will be able to compile the functions defined inside other functions and that return vectors by value?
Scalars and even strings are fine. Is it some sort of preprocessing issue?

madjestic
So it is the variable that is passed as an argument, not the value of a variable, thus allowing changing the state of the variable from another function? Good to know, I expected different.

I tend to use a const keyword to be safe:


type name(const type var)
{
return result;
}

Stalkerx777
Thx for replies guys. I understand your point of view. Assuming this tool is a proof of concepts, it's good to have implemented in nodes, it's very good source of knowledge inside I hope it will get more attention in future release.

SESI generously gives you an opportunity to do some cool stuff by yourself. Ideal software would be so boooooring
But I agree, in most of the cases there are only two main factors: speed and flexibility. As to me a tool that can't be “modified” is not necessary a black box. Unless it can't communicate to other tools. In some “industry standard ™” softwares there is a difference where geometry comes from. So even if we have geometry imported from some in-house format, we still can't paint an attribute on it because the standard tools have no idea about the data structure we are going to work with. It wasn't the case in Houdini before the introduction of custom primitives. Even now if I'm not mistaken it's enough for developer of some custom primitive to provide basic virtual methods in order to let other tools know how to work with that primitive (sure it can be not as simple in the end but I think it should be close to reality).
From this point of view C++ed operators can't be called black boxes. And the fact that they are non-editable is not that big deal. Speed wise they are good. Flexibility wise? Add CVEX based workflow on top of the tool and here we are. This is how I see it.

It's fast and probably the fastest algorithm.

Hi koen,

It's a simple task for point clouds. All what you need is to open a point cloud in some position. First point in point cloud will be nearest point.

#pragma label pcfile “Point Cloud”
#pragma hint pcfile file

#pragma label radius “Radius”

#pragma hint nearest hidden

sop
nearestPoint(string pcfile = “”;
float radius = 1.0f;

export int nearest = -1)
{
int handle;

if(pcfile != “”) {
handle = pcopen(pcfile, “P”, P, radius, 1);
while (pciterate(handle))
{
pcimport(handle, “point.number”, nearest);
}
pcclose(handle);
}
}

Hi Alan,

It's OBJ_Node class, there is a bunch of methods defined in OBJ_Node.h

Cool it works. Thanks for patience Edward!

Opps… At least I know why it crashes ops:

I was using
vtx = new GEO_Vertex();
Is it make any difference to temporary vertex buffer?
Anyway… With GEO_WorkVertexBuffer:
GEO_WorkVertexBuffer vbuffer(gdp);
hlist.bindDetail(ground);
hlist.appendAllAttributes(GEO_POINT_DICT);
/*
There is no method GEO_WorkVertexBuffer::getVertex()
nor GEO_WorkVertexBuffer::getVertex(void)
only GEO_WorkVertexBuffer::getVertex(int idx, GEO_Point *pt = 0)
*/
vtx = vbuffer.getVertex(0); // vbuffer.getVertex(0, ppt) has same effect
ppt = vtx->getPt(); // Not sure why do we need it because we never use it
ppr->evaluatePoint(*vtx, hlist, u, v);
hlist.setElement(vtx);

This code crashes.

edward
I'm not understanding. What/how is it not working? If hlist is NULL, then it's because that attribute doesn't exist.

Accordingly to this test attributes exist:
for(int i = 0; i < hlist.entries(); i++)
{
cout << “Name: ” << hlist->getName() << endl;
}

Result is:
Name: P
Name: uv
Name: tmap
Name: N

I have not zero pointers but zero values:

Attribute = Pointer = value
hlist = 0x333c3f0 =


Which is wrong. All values have to be more interesting.
So hlist->getF(0) && hlist->getF(1) should have non zero values (not only zero values like now)

Thanks Edward!
Unfortunately I can't get proper result with such snippet
hlist.bindDetail(gdp);
hlist.appendAllAttributes(GEO_POINT_DICT);
ppr->evaluatePoint(*vtx, hlist, u, v);
hlist.setElement(vtx);

pos = hlist->getV4();
mapu = hlist->getF(0);
mapv = hlist->getF(1);

gdp is fine, ppr is fine, simpler form of evaluatePoint() returns a proper P, vtx pointer isn't zero, hlist isn't zero, hlist isn't zero, hlist.entries() gives me exactly the same number of attributes + 1 (is it because P automatically counts as attribute?), hlist always gives me zero so everything looks okay.
But pos, mapu, mapv (and others) are always zero. What I'm doing wrong?

Hello,

Is anyone knows how to achieve (within the HDK) the same functionality which HScript expression function primuv() has?
There is a method from GEO_Primitive class:


virtual bool evaluateInteriorPoint(GEO_Vertex &result, GEO_AttributeHandleList &hlist, fpreal u, fpreal v) const;


It looks like what I'm looking for but I'm not sure how to deal with GEO_AttributeHandleList &hlist.
Is it the object that determines which attributes to sample, how to interpolate them etc? How shall I initialize it?

For instance:


const GEO_Primitive *ppr;
GEO_Point *ppt;
GEO_Vertex result;
GEO_AttributeHandleList hlist;
UT_Vector4 pos;
float u = 0.0f;
float v = 0.0f;

hlist.bindDetail(gdp); // Not sure should I do this
hlist.appendAllAttributes(GEO_POINT_DICT);
ppr->evaluateInteriorPoint(result, hlist, u, v);
ppt = result.getPt(); // This is only for a test purposes I'd rather sample something else than P


In my case ppt is always zero that means ppr->evaluateInteriorPoint(result, hlist, u, v) call fails?
Any suggestions?

Cheers,
-O

> Is the glx or dri module loaded in X?
In the third line of glxinfo “Computer says yeeeeeessss”
And X.org log says exactly the same.

>And how can you say that blender runs fine????

If I run Blender and it works without slowdowns and any glitches I could say “it works fine”. Actually not only Blender but also other simple OpenGL applications too (for instance Chromium without DRI slow as hell even on more powerful systems, but in my case it's fast).
What is suspicious to me in those 3 GLX visuals - all of them doesn't support accumulator. :?

I know, I know… There is already answer “Do not use on board Intel video cards with Houdini” and I can agree with it but there are some cases when you just have no choice
I was able to run Houdini on my netbook with Kubuntu 8.04. It was working pretty well (not the most stable and fast solution ever but it was okay for some simple tests). Unfortunately it doesn't work in Kubuntu 8.10. I'm not sure which version of X.org / drivers exactly I had before but now what I see is just such message:
ERROR: could not obtain GLX visual!
Most likely cause is a lack of 3D acceleration. Check your configuration.
That's all good but as I understand everything is “fine” regarding to DRI.
glxinfo gives this information:
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_visual_select_group
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 945GME 20061102 x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 7.2
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_multisample,
GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_shadow,
GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra,
GL_EXT_blend_color, GL_EXT_blend_equation_separate,
GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax,
GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_cull_vertex,
GL_EXT_compiled_vertex_array, GL_EXT_copy_texture,
GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels,
GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_separate_specular_color,
GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture,
GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp,
GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle,
GL_EXT_vertex_array, GL_3DFX_texture_compression_FXT1,
GL_APPLE_client_storage, GL_APPLE_packed_pixels,
GL_ATI_blend_equation_separate, GL_ATI_separate_stencil,
GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat,
GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture,
GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent,
GL_NV_point_sprite, GL_NV_texture_rectangle, GL_NV_texgen_reflection,
GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_OES_read_format,
GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture,
GL_SUN_multi_draw_arrays

3 GLX Visuals
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
———————————————————————-
0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x54 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None

36 GLXFBConfigs:
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
———————————————————————-
0x55 0 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x56 0 tc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x57 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x58 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x59 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x5b 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x5c 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x5d 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x5e 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x5f 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x60 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x61 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x62 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x63 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x64 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x65 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x66 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x67 0 dc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x68 0 dc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x69 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x6a 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x6b 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x6c 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x6d 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x6e 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x6f 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x70 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x71 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x72 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x73 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x74 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x75 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x76 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x77 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x78 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow

Also Blender works fine (surprise!). Could you clarify what kind of GL extensions / GL visuals / whatever Houdini is looking for? Just to check in case if I can upgrade a kernel / driver to make Houdini work.
And the last question - should
export HOUDINI_OGL_SOFTWARE=1
work in such case? Because for some reason it doesn't.

Thanks.

Now it's clear edward. Thanks.

initBounds() creates wrong limits of bounding box. Min vec instead of max vec and vice versa.
BBoxMin =
BBoxMax =
H9.1.144

Mantra supports vertex normals. So you can for example use Facet SOP, Edge Cusp SOP or something else to create hard edges and then promote N as vertex attribute onto original geometry. Mantra will use it. Yep, a bit painful workflow.

PythonSOP is not very efficient for manipulating huge amount of data since it's… Python. In case of heavy tasks, as soon as you have your points created, you can switch to VEX scripting, which lets you modify your geometry (points and attributes mostly) with a speed of compiled and multi-threaded C++ code.
Just one remark: everything is true but the best benefits you can get from optimized algorithms not from the language itself. It's possible to make Python 100 times faster in some cases when you use optimized data structures like trees. And I'm wondering is it possible to use stackless Python with Houdini? Maybe someone here has such experience.