Thanx for the answers everyone,
some more testing shows that it appears to be related to jpgs.
pngs display fine. but jpgs fail. no matter where they come from, no matter
where I try to display them (on a button, StandardItem, GraphicsView).
can someone give this a short try and confirm?
and
These are the moments where the Log Values node comes in handy. See also:
long arrays.
On 6 February 2013 13:14, Fabricio Chamon xsiml...@gmail.com wrote:
no, afaik.
here's something: it displays the attribute on the closest point to the
bbox center of the cloud. (ignores default values)
nice, tried something similar. obj to point context, but than i couldn't
display just one value ;P
thanks fabricio
Am 06.02.2013 um 14:14 schrieb Fabricio Chamon xsiml...@gmail.com:
no, afaik.
here's something: it displays the attribute on the closest point to the bbox
center of the
While I appreciate the software's efforts to cache only the ICE attributes
that it deems necessary (unless I list all the ones I want - in this case,
many); can we please, please, get a Just bastard cache everything, I don't
care how big the cache files are button?
I've lost hours today trying
+1 for brute cache !
Am 06.02.2013 um 15:06 schrieb Dan Yargici danyarg...@gmail.com:
While I appreciate the software's efforts to cache only the ICE attributes
that it deems necessary (unless I list all the ones I want - in this case,
many); can we please, please, get a Just bastard cache
long way around but definitely a brute force approach. make a custom
attribute display for each attribute you need storing.
On 6 February 2013 14:14, Sebastian Kowalski l...@sekow.com wrote:
+1 for brute cache !
Am 06.02.2013 um 15:06 schrieb Dan Yargici danyarg...@gmail.com:
While I
Thanks Rob.
Yeah, I know about that one but it's just so hacky and shit, frankly.
There really needs to be a fool-proof fallback implemented once and for
all.
DAN
On Wed, Feb 6, 2013 at 4:21 PM, Rob Chapman tekano@gmail.com wrote:
long way around but definitely a brute force approach.
I know I know, I used to have various hacky ways to 'force' an
attribute to be stored in a cache. daisychaining them or storing
userdata in the color or whatever ;) all of them have failed me at
some point until I happened upon a demo ICE topo scene provided by
Ciaran Moloney and saw that every
one way of doing it is to put a Log Values between the data and the
setData node. Even if the log node is muted, Log is unchecked, this node
forces the attributes to be evaluated.
Cheers
Vladimir
On Wed, Feb 6, 2013 at 3:51 PM, Rob Chapman tekano@gmail.com wrote:
I know I know, I used to
I've got used to it, but still one of this small things that would ease up my
daily routine ;)
.sebastian
Am 06.02.2013 um 15:51 schrieb Rob Chapman tekano@gmail.com:
I know I know, I used to have various hacky ways to 'force' an
attribute to be stored in a cache. daisychaining them or
I would still advise using the forcing to be done through some
arithmetic nodes - like adding a zero vector to point positions etc.
Alok
Lead TD
Modusfx
On 06/02/2013 11:14 AM, Vladimir Jankijevic wrote:
the problem with this is that with the log node present in the tree,
the icetree will
The position returned from the location is local with respect to the object
with the tree. In this case, that's the null that you are driving which is why
you are getting strange behaviour. It's much better to put the tree on a rig
null and leave that at the origin.
BTW the reason that Add
Thanks for the tips everyone.
Just using an extra null to host the ice tree seems already to fix my
problem.
Raff : Avoiding local kine make sense to me. I always use Globals when I
write SCOP so I should be safe. Thanks for the confirmation.
Ahmidou :
I'm a bit confused by what you say. The
I'd second that.
I normally use all attributes I want to force evaluation for to construct a
zero length 3D vector. Then I do*GetPointPosition -- AddMyZeroVector
-- SetPointPosition* as the last Execute in my tree.
Has been working this way for me for years now.
Cheers, Martin
--
funny thing is I have not really been having these problems here - cache away
on the farm here and all attributes we wanted cached have worked so far [touch
wood and hope that I did not just put a curse on it].
S.
Sandy Sutherlandmailto:sandy.sutherl...@triggerfish.co.za | Technical
Hi Sandy,
This is a well-known issue for ICE for quite some time now. I am
intrigued you have not faced it so far. Most probably you are not
caching some user-defined (custom) attributes in your scenes. If you
are, then probably you are using these attribute down somewhere in your
tree which
Anybody know what coordinate space is used for the values returned by the
OGLLight? (e.g. OGLLight.GetLightPosition(), OGLLight.GetLightDirection(), ...)
The documentation doesn't specify.
Matt
In a lazily evaluated graph (mostly anything in Soft, and most DCC apps in
fact) you try to compute the bare minimum, which means you travel upstream
from the necessary to the data.
IE: object is moved in viewport, things necessary to draw it are inspected
until all data found is aligned with the
Not sure, but as far as I can remember,
it uses homogenous coordinates so point (x, y, z) is represented
as (xw, yw, zw, w). If you are getting a return of four scalars
and want to convert to 3d cartesian , simply divide the first
three values by the fourth
Ahmidou
I'll try that ;-) Thanks !
Should be global, but again not sure
On 06/02/2013 6:34 PM, Matt Lind wrote:
Let me rephrase what coordinate
space is returned: local? Global? Screen? Normal? Camera?
Thanks,
I mean output to an ICE par, not to a CP par, which is akin to hitting your
testicles with a large mallet.
On Thu, Feb 7, 2013 at 11:07 AM, joshxsi josh...@gmail.com wrote:
FYI, outputting to a parameter to ICE is around 10x slower than outputting
to a transform, so I highly recommend that if
Hi Matt,
Coordinates returned by OGLLight should all be in global space. Are you seeing
any weird behavior with it?
Thanks,
John
From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Alok
Sent: Thursday, February 07, 2013 7:37 AM
To:
I'm used to writing mental ray shaders. Mental ray uses different coordinate
spaces for every scene item which means shader code contains many conversion
routines to do simple stuff like diffuse shading.
I'm still getting my feet wet with OpenGL shaders using the Phong shader you
sent me a
24 matches
Mail list logo
