Yes, they do use different algorithms for dealing with vertex uvs.
Specifically, “Smooth Vertex UVs” isn't used in Mantra. This should only be a difference with coarse levels of subdivision. You should get more similar behaviour if you turn off the Smooth Vertex UVs option.
Note also that creasing is not supported inside Mantra.
- Jeff Lait
Found 390 posts.
Search results Show results as topic list.
Technical Discussion » Subdivision SOP v Subdivision at OBJ level
- jlait
- 6179 posts
- Offline
Houdini Lounge » Houdini & Games
- jlait
- 6179 posts
- Offline
The basic idea they had is pretty much the same thing as I described. It would be nice if someone from SESI would shine a little light on Proceed. I'm curious as to how far they got, and what issues they faced.
The biggest issue faced was a disconnect about *why* one would want to include Proceed. Often people would see it, and think: “How many particles per second?”, which, of course, is the wrong question. If you have to ask that question, it would not be for you. This is radically different from most middleware offerings which are about providing greater speed than your in house solution. An in house particle system or motion system could *always* outperform Proceed by a few orders of magnitude. What they can't provide is the ability to leave look generation in the hands of an artist. (It doesn't help that most game shops are programmer heavy, so think they can spend the cycles to do that themselves :> Ironically, this should actually make Houdini *more* attractive as there are more resources for integration)
The advantage of Proceed is that it allows the artist to write the code for your particle simulations. A more advanced version would have allowed the artist to write the code for your character builders. Or your motion blending. Or camera blending.
Genki ended up using Proceed in Jade Cocoon 2. It is the “custom C++ output driver” mentioned in this write up:
http://www.sidefx.com/products/profiles/genki/ [sidefx.com]
(and perhaps starts using the GPU for computationally intensive POPs, etc.).
Still wating for being able to read textures inside the vertex shaders. I think I read that the DX9 vertex 3.0 shader can do this.
If the display technology (OpenGL 2.0) was there,
Still waiting for arbitrarily long shaders to be supported. The new 3DLabs card promises this.
- Jeff Lait
Technical Discussion » Houdini Apprentice and an old SGI
- jlait
- 6179 posts
- Offline
MichaelC
One question though for any Irix users. Houdini was really washed out the first time I started it, so I adjusted the gamma in Irix's display settings to fix it.
Rather than struggling with the Irix system to change the gamma, you can just change Houdini's internal gamma. This will change the gamma used for all the UI, but you will still have to keep the Octane's gamma in mind when rendering.
To change Houdini's gamma, try setting:
setenv HOUDINI_UI_GAMMA 1.2
You can also play with HOUDINI_UI_CONTRAST, HOUDINI_UI_BRIGHTNESS, and HOUDINI_UI_SATURATION.
As for avoiding ftping all the time, you can mount each other's drive using NFS. If your octane is named “octane” and linux “linux”, doing something like:
on octane:
mkdir /n
in /etc/fstab, add
linux /n/linux nfs exec,dev,suid,rw 1 1
I think a similar process would work for the cross mount. THen you can set your paths to /n/linux/…. and have the hip file work on both systems without change.
Technical Discussion » Cooking Controls + Capture Painting == not so good
- jlait
- 6179 posts
- Offline
MichaelC
I was expecting I could just brush the surface at a normal speed, and the weights and colors would update on MB up. If I set cooking controls to never, I can't paint weights at all. The pointer just freezes in the viewport while the the mouse button is down, and nothing changes if I hit update.
Unlike most SOPs which are defined entirely by their parameters, the paint sops (CapturePaint, Paint, Sculpt, Comb) use the parameters to update an internal represenation of the change in the geometry. This means that if the SOP wasn't recooked as you moved the mouse, you would just get the effect of the last mouse position.
- Jeff
Technical Discussion » reactivate apprentice license loops...
- jlait
- 6179 posts
- Offline
wes_sin
I am using NT 4.0 and installed a copy of Non-commercial houdini 5.5.151.
The license expired on 12-nov-2002, and I tired reactivate it during starting houdini but I was given the expired license again and again. I have checked my system date and restarted the computer. Anyone got a clue what's wrong?
The license server, to save itself work, will just send back your previous keys if they are still valid. Unfortunately, it seems the license server and your machine had a different idea about when midnight was. This would be why it mysteriously started to work later - the license server finally moved over to a new day.
What time zone are you in?
- Jeff Lait
Technical Discussion » Major SOPs problems... please answer this
- jlait
- 6179 posts
- Offline
MichaelC
Also, what's the difference between choosing polygon or polygon mesh? I noticed that polygons seem to have interior geometry when you increase the initial subdivisions, and also interior braces. They look like spring objects. Polygon Meshes however act like polygons in Max or Maya.
Both the “polygon” and “polygon mesh” options in the Box SOP will generate polygons. If you middle click on the icon of the Box, it will tell you the number of primitives and what types - in these cases all polygons.
The difference you are seeing is likely when you turn on “Divisions” to try to get something with more pieces than a unit cube. The Polygon mode does the interior braces which you have noted, while the Polygon Mesh does what you expect. The reason for this is historical. The Lattice SOP requires the interior points to do its deformations, and in the pre-subd world the primary use of the box-sop-with-divisions was to feed the lattice sop. With Houdini 5.0 we added the Polygon Mesh option to match people's expectations.
As for the polysplit causing bad behaviour, I am sending you a private message as we would like to track down the source of this problem.
- Jeff Lait
Houdini Lounge » Page layout
- jlait
- 6179 posts
- Offline
Okay, I believe the board is now 1024x768 friendly. There will still be a scroll bar on the bottom of the screen, but you will note that the right hand side should line up with your vertical scrollbar.
- Jeff
- Jeff
Houdini Lounge » Page layout
- jlait
- 6179 posts
- Offline
Ack! You are quite correct. If it makes you feel better, I'm running 1kx768 right now so feel your pain. In our defense, our test forum did have enough whitespace at the right to ensure it fit in a 1k window. Unfortunately when I embedded it in the live pages I seem to have lost that spacing. I won't be able to adjust it until I get back, so please bear with it for now.
- Jeff
- Jeff
Technical Discussion » new L-sys variables...
- jlait
- 6179 posts
- Offline
As of 5.0 (4.9.466 to be precise) several improvements were made to the lsystem sop to better support the polywire sop. Here's a copy of what I wrote at the time…
- The point width attribute is multiplied by the thickness value
of the lsystem, so will match the diameters of the tube
generation. - Generations over 127 produce the correct generation number.
- When point attributes are generated, we create more than just
the width attribute: - segs ($SEGS), an integer point attribute for the number of
segments (rows) tubes leaving that point should have. - div ($DIV), an integer point attribute for the number of
divisions (columns) tubes leaving that point should have. - lage ($LAGE), the age of the point in the lsystem.
- arc ($ARC), the arc length from that point to the root of
the lsystem. - up ($UP[XYZ), the up vector for the tubes birthed at that
point. - gen ($GEN), the integer generation of that point.
- When point attributes are created, the system's points are
automatically sorted by generation. This means point numbers
will match from generation to generation, allowing motion blur,
etc.
lage is the vertical increment of the lsystem from the tube parameter folder. Either arc or lage makes a good value for the v texture coordinate. If you go to the preset menu of the polywire sop (in 5.5 you'll have to expand the hidden bar at the top of the parameter window) you'll find a “forlsystems” preset which fills in most of the stuff from the lsystem variables. For texturing I usually put in ($ARC, $ARC2) in the v texture parameter as well.
I hope this clarifies things.
- Jeff
Technical Discussion » RESOURCES file and fonts question
- jlait
- 6179 posts
- Offline
scottwade
This isn't essential, obviously just a cosmetic issue I get back to occasionally, but actually making the GUI font smaller and the ability to change the GUI font to something other than the stock fonts is what I'm after.
I have some good and bad news about Houdini 5.5 then. The bad news is that HOUDINI_OVERRIDE_HEIGHT & WIDTH won't work directly. The good news is that you likely won't need them. The “Giant Font” problem on NT which caused so many to run to the HOUDINI_OVERRIDE variables was caused by Windows reporting everyone's monitor sizes as 12 inches (30 cm). As very few people run 1280x1024 on a 12 inch monitor, we were calculating absurdly high DPI for people's screens. Since our UI is specified in inches rather than pixels, this had the effect of inflating everything.
With Houdini 5.5 we ignore the value returned by Windows entirely, and instead set the DPI to a fixed value (which should match what you see on other platforms). Also, as the HOUDINI_OVERRIDE_* functions were rather obscure in both their use and what values to set them at, the variable HOUDINI_UISCALE was added to provide a one stop scaling factor. A value of 100 is the default 85 dpi. Higher numbers will give larger text, smaller numbers smaller text. A value of -1 will cause it to use teh HOUDINI_OVERRIDE variables if you have something you like already in there.
Which points me back to Houdini not having the appropriate binary and metrics files for that font under /fonts and /fonts_gl. That's why I'm wondering what the specific format of those .bin files are under /fonts_gl. I can generate both the postscript binary outlines for the /fonts directory, and the metrics for whatever font I'm trying to use, but cannot figure out what exactly needs to be under those directories in order to use a non-stock font for the GUI itself specified in the resources file from a valid font.index item.
You are correct you need an appropriatley formatted .bin file for the font. Unfortunately I think we use our own bizarro format. The .bin files are just brute force binary conversion of our ascii font format. And, our ascii font file is, to my knowledge, yet another custom file format.
- Jeff
-
- Quick Links