Public Beta: Trestle & Scrim

[bronco]

another thing: when the plugin windows are open, it is not possible to navigate in EIAS viewports. i know this is something that is possible only recently, but i think it would be nice to view the models from all directions when finetunig the settings.
please incorporate the functionality.

[Vizfizz]

ok, last test with this fake-soft-body-typ-of-thing.
it now has high-tech interconnections, so that if one chain of controllers is affected by some force the others will follow.
well, high-tech as in sledgehammer, hehe.

TS04c-mp4.mov

still no sideway movement, thats why it looks funny at the end.

Please, Igors, make Trestle 3d.

ok, from now on i’ll venture into other aspects of trestle and scrim.

Hey Uwe…

The Scrim shadows look better. Did you up the uniform resolultion or is this beta 4 of Scrim and the shadows are acting better for you?

[bronco]

i upped the resolution to 200 and triangulated the stuff. that took care of the shadows, but that’s only a workaround. a solid plane should cast a solid shadow.

[Vizfizz]

Whew… that’s a bit overkill… yes… definitely, you’re right. As for interactive windows with the plugin still open…I’ll check with the Igors.

[Igors]

Hi, Uwe, Brian

The Scrim shadows look better. Did you up the uniform resolultion or is this beta 4 of Scrim and the shadows are acting better for you?

i upped the resolution to 200 and triangulated the stuff. that took care of the shadows, but that’s only a workaround. a solid plane should cast a solid shadow.

We d/loaded the movie, but don’t understand shadow problems you talk about. Please post a bug prj

[Vizfizz]

Just look at the shadows of the first Uwe “fake softbody” test. The shadows generated on the surface of the scrim object breaks apart and if you look at the shadow casted on the floor, you can see breaks in the shadow with light.

[bronco]

hey Igors, you can find the shadow problem in post #54. with project file.
any news on z values?

[Igors]

Hi, Uwe

you are absolutely right, scrim is no cloth simulator, never intended to be. that’s why i used the word fake
but, i think with a little work, on both ends - programer and user, it has the flexibility to be more than intended. it has limitations, sure.

Sorry, Uwe, but we don’t share your opinion. It’s impossible to be “half-pregnancy”, any cloth simulation, from very simple up to very complex, needs absolute concrete things like forces, fibers’ resistance etc. The Scrim never will be a cloth simulator simply cause it never was designed to do this

i guess what i really want to say is this:
make all plugins as open as you can, not just scrim and trestle. give the user the posibility to access all posible animation channels, you’ll never know what your own plugin is capable of.
(i am good at pushing the limits )

This story is not a new However, we think an artist’s creativity should not be used instead of absent physics engine (cloth simulator). The “normal” solution for your movie would be: create a mesh and a animated sphere (just Ubershapes) and run a simulator to solve all rest: collision detections etc. Do you prefer more complex way? Of course, it’s your affair and you can use plug-in absolute for all you want (count things absolute outside of our imagination). But please agree: it does not mean that a plug-in should be suitable for absolute all you designed The Scrim builds a surface between cross-sections, this functionality is clear and guaranteed.

[Vizfizz]

Hi, Uwe
Sorry, Uwe, but we don’t share your opinion. It’s impossible to be “half-pregnancy”, any cloth simulation, from very simple up to very complex, needs absolute concrete things like forces, fibers’ resistance etc. The Scrim never will be a cloth simulator simply cause it never was designed to do this

This story is not a new However, we think an artist’s creativity should not be used instead of absent physics engine (cloth simulator). The “normal” solution for your movie would be: create a mesh and a animated sphere (just Ubershapes) and run a simulator to solve all rest: collision detections etc. Do you prefer more complex way? Of course, it’s your affair and you can use plug-in absolute for all you want (count things absolute outside of our imagination). But please agree: it does not mean that a plug-in should be suitable for absolute all you designed The Scrim builds a surface between cross-sections, this functionality is clear and guaranteed.

Spoken like true programmers. Nothing wrong with that…but guys I gotta tell yah I’ve worked in nearly every animation environment on the planet and this type of “debate” goes on and on and on between artists and developers. Both sides have legitimate positions.

Igors: You are absolutely right to declare that Scrim is not a cloth sim. I’ve said it, you’ve said it. People, I believe, will understand that. I didn’t even bring it up. Uwe did what was natural when seeing the functionality of this plugin. Animatible control wires that manipulate geometry! Hmmm… I bet I could use this to make cloth. What you’re attempting to control is the creative process that animators and artists take in order to complete a task. Is a simulation the best solution as you suggest? No, not always. They are certainly more convenient and might also give you the most realistic look, but, they also have their weaknesses. I’ve been on projects where I’ve hand keyed clusters in Maya to fake cloth because it was actually easier than trying to set up a simulation. Simulations aren’t always the answer. All the users are looking for Igors is a bit of fuzzy logic. Not everything has to be black or white when it comes to animating.

Artists: Try to place yourselves in the developers shoes. They are writing a specific plugin to accomplish a specific task. When the plugin is marketed and sold, if it does what its intended to do its a good thing…but if we try to promote it like its something else, we run into problems with user expectations. Not everyone has Uwe’s skill and capabilities with Rodeo. Users will gripe that they can’t accomplish the same thing Uwe has accomplished. Rodeo isn’t even available. Therefore we ask you to focus on the product’s intended purpose. If you can stretch the plugin to do more, that’s great. Tell your friends how you did it…but just realize the differences of philosophies here.

What is the solution? Well the only true way to get around situations like this is to truly examine the desired request from a couple of factors:

1. Is the request truly aligned to the plugin’s original intentions?
2. Will the request bring unreasonable production times to implement into the code?
3. Can all users benefit from the request rather than just one?
4. Does the request increase the value of the plugin from a marketing standpoint?

[Igors]

Hi, Uwe

Thx for prj, d/loading now, we’ve not noticed the link inside other text

now the fun:
dear igors, i have noticed that the control points have z position values, which, of course, don’t have any meaning.
i completle understand that these values are not editable with the graph editor.
can you make them editable via XP? true 3d wires?
in the example above the use of trestle is somewhat limited because it is only operating on a 2d plane. there is no sideway movement.

Let’s try to be “principal” and see things more globally (why we cannot? ). So, from this point of view: do we plan a 3D-editor? No. Cause, at least, it needs direct manipulations in all EI windows. Ok, do we plan a 2D editor? Yes. What do you propose? To add "some 3D-functions to 2D-editor ", right? So, what we should answer to user if he asks: “is it 2D or 3D editor”? IMO the normal answer is: “it’s 2D editor only. You can deform a plug-in’s output or use Path2Line to make 3D contours”. Imagine another answer: “it’s 2D editor with outside Z editing”(?). This answer immediately initializes a series of new questions (that have not good answers) and a critique (absolute deserved), like: “How I can edit Z ?”, “Why there is no any interactive Z-editing?”, “How can I find a needed point in a large list of animation channels?” and many, many others. What we should to answer, Uwe?

now let’s dream, shall we?
if trestle would operate true 3d and patrick would get his things together and start on rodeo again, then we would be only a few steps away from, at least, fake soft bodys.
Maybe i am talking bull**** here, but i think the potential is here.
Your opinions?

Well, IMO soft body is not sooo awful as it looks first The fake you propose looks much more complex than a normal soft body simulation with techniques that are not a secret long ago. Of course, we don’t want to say that a soft body is “a piece of cake”, it’s a large work, but… hey, how it’s related with our thread?

[bronco]

whoa, you misunderstood me.
i didn’t mean that you should make scrim a cloth simulator. i understand that this will not happen.
all i wanted to point out is that if you give trestle the ability to have z values for the control points there is much more use for it. if it is only accessable through XP, so be it. if it takes to much development time, ok, i understand. there are things that are more important (like shadows).

[bronco]

“How I can edit Z ?”

Xpressionist, it’s build in EIAS

Why there is no any interactive Z-editing?"

because it’s main purpose is 2d

“How can I find a needed point in a large list of animation channels?”

like all animation channel values, twirll down the little triangle
have you looked at übershapes animation channels? nothing can beat this!

What we should to answer, Uwe?

my answere would be: it’s 2d, with a twist
all comes down to this: if it is easy for you to add z values (not directly editable in graph editor), so for heavens sake just do it. it’s like an easer egg for XP users.
if it is not so easy, than let it go.
path2line has no control points, so different functionality, different setup.

hey, how it’s related with our thread?

because it is build with trestle and scrim! as far as i know trestle is the first time to have control over a wire via control points in EIAS. this is nice! this is great! it would be even better in 3d.

ok, think about it. do what you think is best for the plugin. i will stop nagging about z values.

[Igors]

Hi, Brian

1. Is the request truly aligned to the plugin’s original intentions?
2. Will the request bring unreasonable production times to implement into the code?
3. Can all users benefit from the request rather than just one?
4. Does the request increase the value of the plugin from a marketing standpoint?

Let us answer

#1. No, this idea has nothing in common with plug-in’s original intentions

#2. The implementation requires some time, efforts and accuracy (same as any work)

#3. Nobody knows how a program (or its part) is usable if it’s not written yet

#4. We sure that no

Now we’ve a question We don’t know is a proposed replication good or bad, but please explain: WHY it’s planned inside Trestle and WHY user can replicate this plug-in only? Why it cannot be applied to ANY group?

[Igors]

Hi, Uwe

hey Igors, you can find the shadow problem in post #54. with project file.
any news on z values?

Learned, Raytracer doesn’t like non-planar quads. Simply check “Triangulate” in the plug-ins interface

[Vizfizz]

Taking my last post into consideration, we need to talk about Trestle’s replication feature.

Here’s the situation:

We recognize the value of providing cross section replication to help reduce the labor involved in placing mutiple trestle instances. However, because of EIAS’ plugin api, Trestle can not create independant replicants that possess their own individuality. If you create 5 copies of a cross section in Trestle, EIAS will generate 5 cross sections, but those cross sections will be considered a single object.

I have suggested to the Igors that they expand Trestle’s replication capabilities to include:

1. Replication in a single direction. (To create rows or columns of duplicates)
2. Replication in two directions. (To create a 2D grid of duplicates)
3. Replication in three directions. (To create a 3D array of duplicates)

I suggest XYZ positional values between duplicates be animatible and be either “uniform” or “exponential/additive” distances apart for each replicant.

Additionally, I wish to add animatible “uniform” and “additive” rotational and scale capabilities to Trestle.

The question has been asked… does this have value and does it meet with the original purpose Trestle was created for?

My response is: Yes…and here’s why.

1. Creating rows, columns, or grids of 2D cross sections in a single trestle instance can then be manually duplicated in EI and lofted together with Scrim to create fast and easy repetitive geometry. As in the example of a picket fence, or tiles, or architectural support beams… etc etc etc.

2. Activating surfaces instead of wires will allow Trestle to be combined with a particle engine and unique surface emissions can be obtained especially when the surfaces can be controlled with animation functions.

3. Geometry based lighting grids and arrays can be rapidly made for GI/Radiosity.

4. When adding rotational and scaleable animation controls into the equation, unique and precise forms can be made.

5. Plugin overhead is reduced. One plugin can control one to dozens of replicated items. If individual control over every cross section is required, the user can simply use mutiple instances of Trestle instead.

What do you users think? Stephane, I’d like to hear your take on this. How could you have done your animation test differently if you had the ability to animate position, rotation and scale?

[Vizfizz]

Hi, Brian

Let us answer

#1. No, this idea has nothing in common with plug-in’s original intentions

#2. The implementation requires some time, efforts and accuracy (same as any work)

#3. Nobody knows how a program (or its part) is usable if it’s not written yet

#4. We sure that no

Now we’ve a question We don’t know is a proposed replication good or bad, but please explain: WHY it’s planned inside Trestle and WHY user can replicate this plug-in only? Why it cannot be applied to ANY group?

Ok… my turn to answer all of these questions.

1. Is the request truly aligned to the plugin’s original intentions?
2. Will the request bring unreasonable production times to implement into the code?
3. Can all users benefit from the request rather than just one?
4. Does the request increase the value of the plugin from a marketing standpoint?

1. Adding z position control to Trestle does meet with the plugin’s original intentions. Trestle is designed to create wires for lofting and surfaces for extruding. Control points provide the means to introduce animation into the equation. If a control point can not be animated in the Z position, you ulimately limit the animation capabilities of the plugin. So Trestle doesn’t permit 3 dimensional positioning of control points in the plugin interface… so what… who’s to say it wont in the future. I agree with you Igors that drawing curves in the Host’s orthographic windows will be the most ideal… but that opportunity may never happen. Uwe is correct. This is the first time control points can be moved within EI and the users have been begging for this for years. What’s the harm of including the capability to animate a control point in Z space. Its like saying here’s a car for you to drive, but you can only drive in reverse. If Xpressionist can tap into control point’s Z channel, then we should give them the opportunity to exploit it.

2. From you answer it doesn’t sound like it would take a huge effort to impliment access to the Z channel. Its ok right now that Trestle’s editor can’t draw in the Z plane… that could change…

3. Well… of course. We don’t know how users will use the plugin… but shouldn’t we give them the ability to really take advantage of it? If its just a small implementation… what harm is it?

4. Will it increase marketability? Well… z channel point control isn’t a HUGE buzz word… but I think the lack of that ability will limit the program more. Users tend to focus on the obvious exclusions. When 6.5r3 came out… did I say cool its perfect… no I stated, “Where the heck is FBX export?” To me that was an obvious exclusion. Seemed strange NOT to include it. We’re just talking about a z channel…

As for you question about replicating in Trestle.

1. There are no step, repeat, and duplicate controls in the host program.

2. Replicating within the plugin reduces overhead. With EI we tend to suffer from the “Just use another plugin” to solve limitations within the Host program. Excessive use of live plugins means more computational overhead. My training has always been (as a previs artist) use the most efficient and effective means of achieve a desired effect without bogging down the system. Huge number of plugin instances or using nested plugins reduces effeciencies and EIAS plugin API is taxed enough as it is.

3. I would love it if EITG would provide more advanced replication calls to achieve step and repeat duplication, but it doesn’t have it. Since we are creating a new plugin based modeling solution, we need to provide that functionality to the user in the best way we can. Since Trestle is acting as our 2D hub for all other future modeling plugins… replicate functions should be considered absolutely necessary. The only caveat we have right now is: If you need individual control over every duplicated object, you’re going to have to use mulitiple hand placed copies of Trestle to achieve the desired results. At least this way, the user has an option.

[bronco]

additional replication features sound very good to me. i can see some use for this.

on a different note:

it seems that i can’t get rid of this pattern, regardless of the settings in scrim:

i tried uniform and adaptive up to 100, triangulated or not, doesn’t matter.

Project File

uwe

[Vizfizz]

I’m curious Uwe…export the model…and bring it back in via Transporter and reset the normals. If the imported geometry renders properly after being “reset” in transporter, then we still have some normals issues in Scrim.

[bronco]

doesn’t make any differents.
i think its just the way straight lines (trestle), b-splines (scrim) and diagonal wave come together.
this brought up another issue:

combinig these values:

result:

same settings with U mode indeces:

[Vizfizz]

Igors and Uwe…

I see by the screen capture that the plugin reads 1.0b3 up at the top of frame…though b4 has been seeded to the beta team. Is it possible an error was made? The beta 4 plug I distributed definitely improved artifacting problems… just wanna make sure we don’t have a mismatch going on.