Un peu tard sur la conversation, par contre pour l'écran je confirme vivement @Nicolas Caplat. Perso j'ai l'équivalent chez Samsung (dalle VA pour le coup au lieu d'IPS) et pareil, je ne reviendrait pas en arrière. Le seul petit default que j'y trouve, c'est le manque de hauteur finalement
Global Variables
A list of variables available in wrangles. The type indicator isn't necessary, but included as a reminder.
sidefx
Available in all SOP wrangles
f@Frame //The current floating frame number, equivalent to the $FF Hscript variable
f@Time //The current time in seconds, equivalent to the $T Hscript variable
i@SimFrame //The integer simulation timestep number ($SF), only present in DOP contexts.
f@SimTime //The simulation time in seconds ($ST), only present in DOP contexts.
f@TimeInc //The timestep currently being used for simulation or playback.
Available in Attribute Wrangle (point, vertex, primitive and detail)
v@P //The position of the current element.
i@ptnum //The point number attached to the currently processed element.
i@vtxnum //The linear number of the currently processed vertex.
i@primnum //The primitive number attached to the currently processed element.
i@elemnum //The index number of the currently processed element.
i@numpt //The total number of points in the geometry.
i@numvtx //The number of vertices in the primitive of the currently processed element.
i@numprim //The total number of primitives in the geometry.
i@numelem //The total number of elements being processed.
Available in Volume Wrangle
v@P //The position of the current voxel.
f@density //The value of the density field at the current voxel location.
v@center //The center of the current volume.
v@dPdx, v@dPdy, v@dPdz //These vectors store the change in P that occurs in the x, y, and z voxel indices.
i@ix, i@iy, i@iz //Voxel indices. For dense volumes (non-VDB) these range from 0 to resolution-1.
i@resx, i@resy, i@resz //The resolution of the current volume.
Common Geometry Attributes
Houdini knows to cast these to the appropriate data type.
Int
@id // A unique number that remains the same throughout a simulation.
// Float
@pscale // Particle radius size. Uniform scale. Set display particles as 'Discs' to visualize.
@width // Thickness of curves. Enable 'Shade Open Curves In Viewport' on the object node to visualize.
@Alpha // Alpha transparency override. The viewport uses this to set the alpha of OpenGL geometry.
@Pw // Spline weight.
Vector3
@P // Point position. Used this to lay out points in 3D space.
@Cd // Diffuse color override. The viewport uses this to color OpenGL geometry.
@N // Surface or curve normal. Houdini will compute the normal if this attribute does not exist.
@scale // Vector scale. Allows directional scaling or stretching (in one direction).
@rest // Used by procedural patterns and textures to stick on deforming and animated surfaces.
@up // Up vector. The up direction for local space, typically (0, 1, 0).
@uv // UV texture coordinates for this point/vertex.
@v // Point velocity. The direction and speed of movement in units per second.
Vector4
@orient // The local orientation of the point (represented as a quaternion).
@rot // Additional rotation to be applied after orient, N, and up attributes.
String
@name // A unique name identifying which primitives belong to which piece. Also used to label volumes.
@instance // Path of an object node to be instanced at render time.
Specifying VEX Data Types
The following characters are used to cast to the corresponding data type.
float f@name // Floating point scalar values.
vector2 u@name // Two floating point values. Could be used to store 2D positions.
vector3 v@name // Three floating point values. Usually positions, directions, normals, UVW or colors.
vector4 p@name // Four floating point values. Usually rotation quaternions, or color and alpha (RGBA).
int i@name // Integer values (VEX uses 32 bit integers).
matrix2 2@name // Four floating point values representing a 2D rotation matrix.
matrix3 3@name // Nine floating point values representing a 3D rotation matrix or 2D transform matrix.
matrix 4@name // Sixteen floating point values representing a 3D transform matrix.
string s@name // A string of characters.
Channel Shortcut Syntax
This is used to hint at the data type of auto generated wrangle parameters.
DOP Particle Attributes
Particle systems are driven by attributes, here are some of the attributes used.
f@age // Time in seconds since the particle was born.
f@life // Time in seconds the particle is allowed to live. When f@age>f@life, i@dead will be set to 1.
f@nage // Normalized age, f@age divided by f@life. Implicit attribute, you cannot write to this.
i@dead // Whether a particle is living (0) or dead (1). A dead particle is deleted in the Reaping stage.
i@id // A unique id for the particle that remains the same throughout a single simulation.
i@stopped // Whether a particle is moving (0) or stopped (1).
i@stuck // Whether a particle is free (0) or stuck (1).
i@sliding // Whether a particle is free (0) or sliding along a surface (1).
f@cling // Force applied to sliding particles inwards (according to the collision's surface normal).
s@pospath // The path to the object that the particle is colliding with.
i@posprim // Which collision primitive in the path geometry whose position we wish to refer to.
v@posuv // Parametric uv on the collision primitive.
i@hittotal // The cumulative total of all hits for the particle (only incremented once per timestep).
i@has_pprevious // This is set to 1 if v@pprevious contains valid values.
v@pprevious // Stores the position of the particle on the previous frame. Used for collision detection.
i@hitnum // The number of times the particle collided in the last POP Collision Detect.
s@hitpath // The path to the object that was hit. A path to a file on disk or an op: path.
i@hitprim // The primitive hit. Could be -1 if it the collision detector couldn’t figure out which prim.
v@hituv // The parametric UV space on the primitive.
v@hitpos // Where the hit actually occurred. Useful if the colliding object was moving.
v@hitnml // The normal of the surface at the time of the collision.
v@hitv // The velocity of the surface at the time of the collision.
f@hittime // When the collision occurred, that could be within a frame.
f@hitimpulse// Records how much of an impulse was needed for the collision resolution. varies with timestep.
f@bounce // When particles bounce off another object, this controls how much energy they keep.
f@bounceforward // Controls how much energy they keep in the tangential direction.
f@friction // When particles bounce, they are slowed down proportional to how hard they hit.
s@collisionignore // Objects that match this pattern will not be collided.
f@force // Forces on the particle for this frame.
f@mass // Inertia of the particle.
v@spinshape // This is multiplied by f@pscale to determine the shape of the particle for rotational inertia.
f@drag // How much the particle is effected by any wind effects.
f@dragexp // Ranges from 1 to 2, default is set on the solver. Used for both angular and linear drag.
v@dragshape // How much the particle is dragged in each of its local axes.
v@dragcenter// If specified, drag forces will also generate torques on the particle.
v@targetv // The local wind speed. Thought of as the goal, or target, velocity for the particle.
f@airresist // How important it is to match the wind speed. Thickness of the air.
f@speedmin // Minimum speed, in units per second, that a particle can move.
f@speedmax // Maximum speed, in units per second, that a particle can move.
p@orient // Orientation of the particle. Used for figuring out 'local' forces.
v@w // Angular speed of the particle. A vector giving the rotation axis.
v@torque // The equivalent of force for spins. No inertial tensor (the equivalent of mass) is supported.
v@targetw // The goal spin direction and speed for this particle.
f@spinresist// How important it is to match the targetw.
f@spinmin // Minimum speed in radians per second that a particle can spin.
f@spinmax // Maximum speed in radians per second that a particle can spin.
</syntaxhighlight>
DOP Grains Attributes
Particles under control of POP Grains have the 'ispbd' attribute set to 1. This causes them to bypass movement update in the POP Solver, as the actual motion update is done by the POP Grains node.
i@ispbd // A value of 1 causes the particle to behave as grains.
f@pscale // Used to determine the radius of each particle.
f@repulsionweight // How much the particle collision forces are weighted.
f@repulsionstiffness// How strongly particles are kept apart. Higher values result in less bouncy repulsion.
f@attractionweight // How much the particles will naturally stick together when close.
f@attractionstiffness // How strongly nearby particles stick to each other.
v@targetP // Particles are constrained to this location.
f@targetweight // The weight of the v@targetP constraints.
f@targetstiffness // The stiffness with which particles are fixed to their v@targetP attribute.
f@restlength// Particles connected by polylines will be forced to maintain this distance (prim attribute).
f@constraintweight // Scale, on a per-particle basis of the constraint force.
f@constraintstiffness // This controls the stiffness on a per-particle basis.
f@strain // This primitive attribute records how much the constraint is stretched.
f@strength // If f@strain exceeds this primitive attribute, the constraint will be removed.
DOP Packed RBD Attributes
The Bullet Solver uses several point attributes to store the properties of each piece of a packed object.
i@active // Specifies whether the object is able to react to other objects.
i@animated // Specifies whether the transform should be updated from its SOP geometry at each timestep.
i@deforming // Specifies whether the collision shape should be rebuilt from its SOP geometry each timestep.
f@bounce // The elasticity of the object.
i@bullet_add_impact // Impacts that occur during the sim will be recorded in the Impacts or Feedback data.
i@bullet_ignore // Specifies whether the object should be completely ignored by the Bullet solver.
f@bullet_angular_sleep_threshold// The sleeping threshold for the object’s angular velocity.
f@bullet_linear_sleep_threshold // The sleeping threshold for the object’s linear velocity.
i@bullet_want_deactivate// Disables simulation of a non-moving object until the object moves again.
i@computecom// Specifies whether the center of mass should be computed from the collision shape.
i@computemass // Specifies whether the mass should be computed from the collision shape and density.
f@creationtime // Stores the simulation time at which the object was created.
i@dead // Specifies whether the object should be deleted during the next solve.
f@density // The mass of an object is its volume times its density.
f@friction // The coefficient of friction of the object.
f@inertialtensorstiffness // Rotational stiffness. A scale factor applied to the inertial tensor.
i@inheritvelocity // v and w point attributes from the SOP geometry will override the initial velocity.
f@mass // The mass of the object.
s@name // A unique name for the object. Used by Constraint Networks.
p@orient// The orientation of the object.
v@P // The current position of the object’s center of mass.
v@pivot // The pivot that the orientation applies to. If i@computecom is non-zero, this is auto-computed.
v@v // Linear velocity of the object.
v@w // Angular velocity of the object, in radians per second.
i@bullet_adjust_geometry // Shrinks the collision geometry.
i@bullet_autofit // Use the bounds of the object for Box, Capsule, Cylinder, Sphere, or Plane.
f@bullet_collision_margin // Padding distance between collision shapes.
s@bullet_georep // Can be convexhull, concave, box, capsule, cylinder, compound, sphere, or plane.
i@bullet_groupconnected // Create convex hull per set of connected primitives.
f@bullet_length // The length of the Capsule or Cylinder collision shape in the Y direction.
v@bullet_primR // Orientation of the Box, Capsule, Cylinder, or Plane collision shape.
v@bullet_primS // Size of the Box collision shape.
v@bullet_primT // Position of the Box, Sphere, Capsule, Cylinder, or Plane collision shape.
f@bullet_radius // Radius of the Sphere, Capsule, or Cylinder collision shape.
f@bullet_shrink_amount // Specifies the amount of resizing done by Shrink Collision Geometry.
s@activationignore // Won't be activated by collisions with any objects that match this pattern.
s@collisiongroup // Specifies the name of a collision group that this object belongs to.
s@collisionignore // The object will not collide against any objects that match this pattern.
f@min_activation_impulse// Minimum impulse that will cause the object to switch from inactive to active.
f@speedmin // Minimum speed, in units per second, that a particle can move.
f@speedmax // Maximum speed, in units per second, that a particle can move.
f@spinmin // Minimum speed in radians per second that a particle can spin.
f@spinmax // Maximum speed in radians per second that a particle can spin.
f@accelmax // Limits the change in the object’s speed that is caused by enforcing constraints.
f@angaccelmax // Limits the change in the object’s angular speed that is caused by enforcing constraints.
f@airresist // Specifies how important it is to match the target velocity (v@targetv).
f@drag // How much the the v@targetv and f@airresist attributes effect the object.
f@dragexp // Ranges from 1 to 2, default is set on the solver. Used for both angular and linear drag.
v@force // Specifies a force that will be applied to the center of mass of the object.
f@spinresist// Specifies how important it is to match the target angular velocity (v@targetw).
v@targetv // Target velocity for the object. Used in combination with the f@airresist attribute.
v@targetw // Target angular velocity for the object. Used in combination with the f@spinresist attribute.
v@torque // Specifies a torque that will be applied to the object.
i@bullet_autofit_valid // Stores whether the solver has already computed collision shape attributes.
i@bullet_sleeping // Tracks whether the object has been put to sleep by the solver.
f@deactivation_time // Amount of time the speed has been below the Linear Threshold or Angular Threshold.
i@found_overlap // Used by the solver to determine whether it has performed the overlap test.
i@id // A unique identifier for the object.
i@nextid // Stores the i@id the solver will assign to the next new object.
DOP RBD Constraint Attributes
Attributes on the geometry to customize each constraint behavior and type. If a primitive attribute with the same name as a constraint property (such as damping) is present, the attribute value will be multiplied with the value from the constraint sub-data.
s@constraint_name // Specifies a piece of relationship data by name, such as 'Glue' or 'Spring'.
s@constraint_type // Specifies whether the constraint affects 'position', 'rotation' or 'all' degrees of freedom.
f@restlength // Specifies the desired length of the constraint to enforce.
f@width // Width of each edge.
f@density // Density of each point.
p@orient // Initial orientation of each point. Value stored as a quaternion.
v@v // Initial velocity of each point.
v@w // Initial angular velocity of each point measured in radians per second.
f@friction // Friction of each point.
f@klinear // Defines how strongly the wire resists stretching.
f@damplinear // Defines how strongly the wire resists oscillation due to stretching forces.
f@kangular // Defines how strongly the wire resists bending.
f@dampangular // Defines how strongly the wire resists oscillation due to bending forces.
f@targetstiffness // Defines how strongly the wire resists deforming from the animated position.
f@targetdamping // Defines how strongly the wire resists oscillation due to stretch forces.
f@normaldrag // The component of drag in the directions normal to the wire.
f@tangentdrag // The component of drag in the direction tangent to the wire.
i@nocollide // Collision detection for the edge is disabled (Only used if Collision Handling is SDF).
v@restP // Rest position of each point.
p@restorient // Rest orientation of each point.
i@gluetoanimation // Causes a point’s position and orientation to be constrained to the input geometry.
i@pintoanimation // Causes a point’s position to be constrained to the input geometry.
v@animationP // Target position of each point.
p@animationorient // Target orientation of each point.
v@animationv // Target velocity of each point.
v@animationw // Target angular velocity of each point.
i@independentcollisionallowed // Toggle external collisions (Only non-SDF Geometric Collision).
i@independentcollisionresolved // Unresolved external collisions (Only non-SDF Geometric Collision).
i@codependentcollisionallowed // Toggle soft body collisions (Only non-SDF Geometric Collision).
i@codependentcollisionresolved // Unresolved toggle soft body collisions (Only non-SDF Geometric Collision).
i@selfcollisionallowed // Toggle self collisions (Only non-SDF Geometric Collision).
i@selfcollisionresolved // Unresolved toggle self collisions (Only non-SDF Geometric Collision).
DOP FLIP Attributes
The FLIP Solver contains an embedded POP Solver, so all of POP Attributes listed above apply.
f@pscale // Particle scale
v@v // Particle velocity
f@viscosity // The "thickness" of a fluid.
f@density // The mass per unit volume.
f@temperature // The temperature of the fluid.
f@vorticity // Measures the amount of circulation in the fluid.
f@divergence // Positive values cause particles to spread out, negative cause them to clump together.
v@rest // Used to track the position of the fluid over time.
v@rest2 // Used for blending dual rest attributes, avoids stretching.
f@droplet // Identifies particles that separate from the main body of fluid.
f@underresolved // Particles that haven't fully resolved on the grid.
i@ballistic // Specifies particles which will be ignored by the fluid solve.
v@Lx // Angular momentum X axis
v@Ly // Angular momentum Y axis
v@Lz // Angular momentum Z axis
DOP Vellum Point Attributes
Vellum geometry is also considered particles, so all of POP Attributes listed above apply.
i@isgrain // A value of 1 causes the particle to behave as grains, 0 behaves as cloth.
f@attractionweight // How much the particles will naturally stick together when close, zero disables clumping.
f@friction // How much to scale the static friction.
f@dynamicfriction // How much to scale the dynamic friction.
f@inertia // Resistance of a particle to rotational constraints. If zero, the particle won't rotate.
v@v // Point velocity.
p@w // (Hair or Wire) angular velocity.
p@orient // (Hair or Wire) orientations.
i@stopped // Used to pin points (0=free, 1=no motion, 2=no rotation, 3=no rotate or move).
i@pintoanimation // If 1, the pinned points' position will be updated to match the target point.
i@gluetoanimation // If 1, both the position and orientation will be updated
s@target_path // target path for any pins (when the Target parameter is set in Vellum Source)
i@target_pt // target point number for any pins (when the Target parameter is set in Vellum Source)
f@targetweight // Affect the strength of the pinned points using a 0..1 weighting value.
i@weld // Weld this point to a point number. If there is an @id attribute, then to a point id.
i@branchweld // built by hair constraints when it is forced to split points for hair simulation.
i@collisionweld // generated on demand to provide a single weld to the detangle algorithm.
f@breakthreshold // The threshold for breaking welds and branch welds
s@breaktype // 'stretchstress', 'bendstress', 'stretchdistance', 'stretchratio', or 'bendangle'.
// Collisions
f@pscale // Used to determine the thickness of cloth or radius of each particle.
f@overlap_self // Stores how much of the original pscale is overlapped.
f@overlap_external // Stores how much of the original pscale is overlapped.
i@layer // Indicates belonging to different layers of cloth. Higher numbers refer to higher layers.
i@disableself // A value of 0 means this point will use self collisions.
i@disableexternal // A value of 0 means this point will use external collisions.
s@collisionignore // Stores a pattern for the objects and collision groups to not collide with.
s@collisiongroup // Gives the collision group that this point belongs to.
// Internal worker variables (Kept to avoid removing/adding attributes every frame)
v@pprevious // For 1st order integration, the previous frames position (beginning of timestep).
v@plast // For 2nd order integration, the position from two frames earlier.
v@vprevious // For 1st order integration, the previous frames velocity (beginning of timestep).
v@vlast // For 2nd order integration, the velocity from two frames earlier.
p@orientprevious // For 1st order integration, the previous frames orientation (beginning of timestep).
p@orientlast // For 2nd order integration, the orientation from two frames earlier.
p@wprevious // For 1st order integration, the previous frames angular velocity (beginning of timestep).
p@wlast // For 2nd order integration, the angular velocity from two frames earlier.
f@dP // Constraint displacements. Likely of last iteration.
f@dPw // Constraint weights. Likely of last iteration.
s@patchname // Identifies each generated patch in a simulation so it can be updated/replaced.
// When a point is part of a Pressure constraint, these attrs hold values computed during constraint update.
v@pressuregradient // a vector pointing outwards along the direction of greatest volume gain.
i[]@volumepts // contains array of the points needed to compute the volume attribute.
i@volume // compare against the Pressure constraint’s restlength value.
DOP Vellum Constraint Attributes
There are many types of constraints, so the meaning of these variables is often dependent on the constraint type. They usually live on the primitive.
s@type // Type of the constraint.
s@type = 'distance' // Each edge in the display geometry is turned into a distance constraint maintaining that edge length.
s@type = 'stitch' // Stitch points within the same geometry together using distance constraints. The points do not need to actually be connected by geometry. This is useful for keeping jackets closed or preventing pockets from flapping
s@type = 'branchstitch' //
s@type = 'ptprim' //
s@type = 'bend' // Each pair of triangles (or implied triangles if input is quads or higher) creates a constraint maintaining the initial dihedral angle between the triangles.
s@type = 'trianglebend' // Each pair of triangles (or implied triangles if input is quads or higher) creates a constraint maintaining the initial dihedral angle between the triangles.
angle
tetvolume
pressure // Each piece, as determined by the Define Pieces parameter, stores its original volume and a many-point constraint is built to maintain it. The enforcement is global, so squishing one place will expand another, like a balloon.
attach, pin
attachnormal
pinorient
bendtwist
stretchshear
tetfiber
triarap
tetarap*
f@stiffness // The stiffness of the constraint, which controls how strongly the constraint pulls.
f@restlength
f@restlengthorig
f@dampingratio // Damping reduces jitter by bleeding energy when evaluating the constraint. Too much damping can prevent the constraint from being satisfied. Values less than 1 must be used.
f@stress // Estimate of work done by the constraint (updated by Vellum solver).
s@constraint_tag // The name of the node which created the constraint
KineFX Attributes
A KineFX hierarchy or skeleton is represented by a collection of points connected by polygon lines. The parent-child relationship between joints in a hierarchy is determined by vertex order.
s@name // joint name attribute
3@transform // World space 3×3 transform of the point (rotation, scale, and shear).
4@localtransform // The transform of the point relative to its parent.
i@scaleinheritance // Determines how a point inherits the local scale from its parent.
</syntaxhighlight>
Viewport Display Attributes
Override the viewport display mode <ref>''[https://www.sidefx.com/docs/houdini/model/attributes.html#attributes sidefx.com/docs/houdini/model/attributes.html]''</ref>
i@gl_wireframe // Detail attribute, force wireframe (1) or shaded (-1)
i@gl_lit // Detail attribute, draw with lighting (1) or no lighting (0)
i@gl_showallpoints // Detail attribute, draw points even if connected to geometry
f@vm_cuspangle // Detail attribute, angle in degrees for generating cusped normals
i@gl_spherepoints // Detail attribute, (1) causes unconnected points to be drawn as spheres
i@gl_xray // Detail attribute, (1) geometry will visible even when it is hidden behind other geometry
v@Cd // Color Diffuse
f@Alpha // Surface opacity
v@N // Surface Normal for lighting
f@width // Curve width
f@pscale // If no pscale exists the viewport defaults to 1.0, while Mantra defaults to 0.1
s@spritepath
s@shop_materialpath
i@group__3d_hidden_primitives // Add primitives to this group to hide them from the 3D viewport
f@intrinsic:volumevisualdensity // Primitive intrinsic attribute controlling the opacity of volumes.
f@volvis_shadowscale // Detail attribute controlling the shadow strength for volumes.
Copying and Instancing Attributes
When copying or instancing, Houdini looks for these point attributes to transform each copy/instance.
https://www.sidefx.com/docs/houdini/copy/instanceattrs sidefx.com/docs/houdini/copy/instanceattrs.html
p@orient // Orientation of the copy.
f@pscale // Uniform scale.
v@scale // Non-uniform scale.
v@N // Normal (+Z axis of the copy, if no p@orient).
v@up // Up vector of the copy (+Y axis of the copy, if no p@orient).
v@v // Velocity of the copy (motion blur), used as +Z axis if no p@orient or v@N.
p@rot // Additional rotation (applied after the orientation attributes above).
v@P // Translation of the copy.
v@trans // Translation of the copy, in addition to v@P.
v@pivot // Local pivot point for the copy.
3@transform or 4@transform // Transform matrix overriding everything except v@P, v@pivot, and v@trans.
s@shop_materialpath // The instanced object uses this material.
s@material_override // A serialized Python dictionary mapping material parameter names to values.
s@instance
s@instancefile // File path indicating what geometry to instance.
s@instancepath // Geometry to instance. This is either a path to a file on disk or an op: path.
</syntaxhighlight>
Accessing Other Inputs
This syntax is used to refer to nodes wired into the inputs of the wrangle, or other nodes in the network.
'opinput:X' is the most legible and always works (the first input is input 0).
point('opinput:0', 'P', i@ptnum)
point('opinput:1', 'P', i@ptnum)
point('opinput:2', 'P', i@ptnum)
point('opinput:3', 'P', i@ptnum)
The integer input number (the first input is 0). Some functions don't support this but it's easy to type.
point(0, 'P', i@ptnum)
point(1, 'P', i@ptnum)
point(2, 'P', i@ptnum)
point(3, 'P', i@ptnum)
@OpInputX works as well, but be careful as it isn't 0 based, instead it starts at 1 which is confusing
point(@OpInput1, 'P', i@ptnum)
point(@OpInput2, 'P', i@ptnum)
point(@OpInput3, 'P', i@ptnum)
point(@OpInput4, 'P', i@ptnum)
v@opinputX_* reads an attribute from the same element on the numbered input (first input is input 0).
v@opinput0_P
v@opinput1_P
v@opinput2_P
v@opinput3_P
Absolute and relative paths to other nodes look like this.
point('op:/obj/geo1/OUT', 'P', i@ptnum)
point('op:../../OUT', 'P', i@ptnum)
For Loop Metadata
Detail attributes, You can get this information with a [https://www.sidefx.com/docs/houdini/model/looping#metadata “Fetch metadata” Block Begin node].
i@numiterations // The expected total number of iterations
i@iteration // The current iteration number, always starting at 0 and increasing by 1 each loop.
f@value // In piece-wise loops, this is the current value of the attribute
i@ivalue // In simple repetition, this is an integer version of value.
Mantra Shader
Mantra shader global variables. See a [https://www.sidefx.com/docs/houdini/model/primitive_spaces.html detailed explanation of implicit parametric UVs]
v@Cf // Surface Color.
v@Of // Surface Opacity.
f@Af // Surface Alpha.
v@P // Surface Position (camera space).
f@Pz // Surface Depth.
v@I // Direction from Eye (camera) to Surface.
v@dPds // Directions or Derivatives of surface implicit s coordinate.
v@dPdt // Directions or Derivatives of surface implicit t coordinate.
v@N // Surface Normal.
v@Ng // Surface Geometric Normal.
v@Eye // Position of Eye (camera).
f@s // implicit parametric s coordinate (u).
f@t // implicit parametric t coordinate (v).
f@Time // Shading Time.
f@dPdz // Change in Position with depth.
i@SID // Sample Identifier. A sample id to be used with the nextsample() VEX function to generate consistent random samples that don’t change when re-rendering or between frames.
Un peu tard sur la conversation, par contre pour l'écran je confirme vivement @Nicolas Caplat. Perso j'ai l'équivalent chez Samsung (dalle VA pour le coup au lieu d'IPS) et pareil, je ne reviendrait pas en arrière. Le seul petit default que j'y trouve, c'est le manque de hauteur finalement
Vraiment merci SugaR pour ton script !
Je vais analyser ça en profondeur, mais déjà, rien que de voir la structure et ta façon de coder, ça m'apprend plein de chose. Je suis comme un peintre en bâtiment qui regarde Michel Ange peindre le plafond de la chapelle Sixtine !
Par contre, tu as le même genre de bug que j'avais eu (avant de mettre les variables en global par dépit): quand tu viens d'ouvrir 3DS (c'est important), que tu lance ton programme et que tu effaces ou copie une sphère, tu as un message d'erreur "removeRollout requires RolloutClass". Mais si tu relance le script ça marche parfaitement.
Hello @archimi.
Projet très sympa, j'avais jamais trop regardé le rolloutCreator perso, je trouve que ca pond vite du code assez pénible a gérer.
Du coup ca m'a quand même motivé a essayer de faire quelque chose en partant de ce que tu as fait. Pour le coup c'est plus un test / exemple qu'autre chose puisque ca permet juste de gérer des sphères.
Je le met ici si ca t'intéresse. Par rapport a ton script, j'ai enlevé la plupart des variables globales (il n'en reste plus que deux) et la liste est entièrement dynamique donc il n'y a normalement aucun besoin de rafraichir la liste manuellement (en gros, n'importe quelque changement dans la scène qui est exposé dans la liste met automatiquement la liste a jour).
Si jamais tu es intéressé par le code et que tu veux en discuter, n'hésite pas à demander (plus sur discord qu'ici mais comme tu veux ).
rol_creator_06.ms
Hello @archimi.
Projet très sympa, j'avais jamais trop regardé le rolloutCreator perso, je trouve que ca pond vite du code assez pénible a gérer.
Du coup ca m'a quand même motivé a essayer de faire quelque chose en partant de ce que tu as fait. Pour le coup c'est plus un test / exemple qu'autre chose puisque ca permet juste de gérer des sphères.
Je le met ici si ca t'intéresse. Par rapport a ton script, j'ai enlevé la plupart des variables globales (il n'en reste plus que deux) et la liste est entièrement dynamique donc il n'y a normalement aucun besoin de rafraichir la liste manuellement (en gros, n'importe quelque changement dans la scène qui est exposé dans la liste met automatiquement la liste a jour).
Si jamais tu es intéressé par le code et que tu veux en discuter, n'hésite pas à demander (plus sur discord qu'ici mais comme tu veux ).
rol_creator_06.ms
Après une eternité sans etre venus ici, je vois que ca parle maxscript, ca m'intéresse
Jamais lus ce bouquin donc je ne peux pas particulièrement en parler. Mais pour ce qui est du commentaire, que ce soit vieux, pas grand chose à dire. En revanche, assumer que l'utilisateur va devoir aller lire l'aide de maxscript, à mon avis c'est très bien. La réalité c'est que même en ayant fais du maxscript depuis maintenant 10ans, je passe toujours ma vie à lire la documentation maxscript. @Nicolas Caplat pourras largement témoigner qu'il y'a a bien souvent des précisions particulièrement utile dedans si on prend le temps de la lire correctement . Donc prendre ce reflexe dès le début me parait plus que nécessaire.
Merci ?
au même titre que à @Nicolas Caplat, je suis toujours prêt à aider (pas ici vu que je ne viens jamais, mais discord ou autre sans soucis). Et pour te mettre au script, le plus simple de toute façon c'est de démarrer avec un tout petit truc, à grand coup de macrolistener. Le code produit n'est pas fou, mais largement suffisant pour démarrer.
En gros, MaxPlus était une vraie API python mais elle à été supprimée dans les dernière versions de 3dsMax. Pymxs n'est qu'un simple wraper de maxscript, mais à l'air relativement complet actuellement. Du coup, il me semble tout de même préférable de démarrer avec maxscript, le language étant plus simple que python mais offre tout de même largement de quoi faire (sauf question UI). Ensuite, passer de maxscript à python est relativement facile, puisque que pymxs c'est littéralement maxscript en python, mais il faut connaitre python bien sur Et pour le coup, 3dsmax est passé sur python 3.9 pour la 2023 je crois (ou ca sera la 2024, pas sur).
Après une eternité sans etre venus ici, je vois que ca parle maxscript, ca m'intéresse
Jamais lus ce bouquin donc je ne peux pas particulièrement en parler. Mais pour ce qui est du commentaire, que ce soit vieux, pas grand chose à dire. En revanche, assumer que l'utilisateur va devoir aller lire l'aide de maxscript, à mon avis c'est très bien. La réalité c'est que même en ayant fais du maxscript depuis maintenant 10ans, je passe toujours ma vie à lire la documentation maxscript. @Nicolas Caplat pourras largement témoigner qu'il y'a a bien souvent des précisions particulièrement utile dedans si on prend le temps de la lire correctement . Donc prendre ce reflexe dès le début me parait plus que nécessaire.
Merci ?
au même titre que à @Nicolas Caplat, je suis toujours prêt à aider (pas ici vu que je ne viens jamais, mais discord ou autre sans soucis). Et pour te mettre au script, le plus simple de toute façon c'est de démarrer avec un tout petit truc, à grand coup de macrolistener. Le code produit n'est pas fou, mais largement suffisant pour démarrer.
En gros, MaxPlus était une vraie API python mais elle à été supprimée dans les dernière versions de 3dsMax. Pymxs n'est qu'un simple wraper de maxscript, mais à l'air relativement complet actuellement. Du coup, il me semble tout de même préférable de démarrer avec maxscript, le language étant plus simple que python mais offre tout de même largement de quoi faire (sauf question UI). Ensuite, passer de maxscript à python est relativement facile, puisque que pymxs c'est littéralement maxscript en python, mais il faut connaitre python bien sur Et pour le coup, 3dsmax est passé sur python 3.9 pour la 2023 je crois (ou ca sera la 2024, pas sur).
Actuellement, AMD met Intel complètement à l'amende sur quasiment toute leur nouvelle gamme, et encore, l'article ne mentionne pas le Ryzen 3950X (pas encore sortis , environ 750$ normalement, 16 cores/ 32 threads) qui devrait bien envoyer. Sans même parler des prochain Threadripper qui devrait avoir un excellent rapport qualité prix (cores / prix surtout), même si certainement très cher (le plus serait sur du 64 cores / 128 threads, 2500-3000$ apparemment).
Par contre les nouvelles cartes-mères AMD sont bien plus cher qu'avant, donc de ce côté il ne devrait plus y avoir d'avantage face à Intel.
Ils ont aussi résolus pas mal de soucis avec la RAM (compatibilité et rapidité).
Pour ma part, j'attends surtout les prochaines cartes Nvidia, voire AMD si elles intègrent le Ray-tracing matériellement pour changer ma config actuelle (vieux hexacore intel). Le ray-tracing sur les cartes graphiques va très clairement changer beaucoup de choses pour nous, donc je verrais pour le CPU à ce moment la, pas dit qu'on ai besoin encore longtemps d'un CPU cher pour la 3D...
Je viens de tomber sur un article comparant les perfs en rendus sous blender 2.9. Ca donne je trouve une bonne indication de la situation Intel vs AMD: https://www.phoronix.com/scan.php?page=article&item=blender-290-performance&num=5
A mon avis, au lieu d'Intel, pars sur de l'AMD, meilleurs perfs pour prix inférieur (surtout dans le rendering). Au passage les nouvelles gammes desktop d'AMD sont pour cette fin d'année si tu peux tenir jusque la ? Sinon le Ryzen 3900X est très bien
Ensuite question carte graphique, pars sur de la geforce à mon avis, les quadro sont inutiles hormis cas spécifique (que je ne peux te renseigner), mais habituellement si c'est juste pour 3ds max, un geforce devrait faire l'affaire et le rapport prix/perfs est largement meilleurs pour les geforce que les quadro. Au passage, la nouvelle gamme nvidia (RTX 30XX) va sortir très prochainement (l'annonce à eu lieu il y a peu).
Et les moteurs de rendus GPU full ray-tracing arrivent (je pense à RedShift principalement), qui vont bien changer la donne, plus nécessairement besoin d'un gros CPU ou d'une render farm..., juste d'une grosse carte graphique plutôt). Dernière demo en date de Redshift:
Tu peux sans problème partir sur un SSD pour le système et un HDD pour les données. Pour la tailles des deux, ça reste spécifique à toi...
Si tu es short question budget, je ne suis toujours pas convaincu que 64Go de Ram soit utile à tout le monde, ça dépend surtout de ton utilisation. Dans tous les cas, tu peux tout à fait envisager de partir sur 2x16Go de RAM dans un premier temps, puis de rajouter 2x16Go plus tard si tu en as besoin
A mon avis, au lieu d'Intel, pars sur de l'AMD, meilleurs perfs pour prix inférieur (surtout dans le rendering). Au passage les nouvelles gammes desktop d'AMD sont pour cette fin d'année si tu peux tenir jusque la ? Sinon le Ryzen 3900X est très bien
Ensuite question carte graphique, pars sur de la geforce à mon avis, les quadro sont inutiles hormis cas spécifique (que je ne peux te renseigner), mais habituellement si c'est juste pour 3ds max, un geforce devrait faire l'affaire et le rapport prix/perfs est largement meilleurs pour les geforce que les quadro. Au passage, la nouvelle gamme nvidia (RTX 30XX) va sortir très prochainement (l'annonce à eu lieu il y a peu).
Et les moteurs de rendus GPU full ray-tracing arrivent (je pense à RedShift principalement), qui vont bien changer la donne, plus nécessairement besoin d'un gros CPU ou d'une render farm..., juste d'une grosse carte graphique plutôt). Dernière demo en date de Redshift:
Tu peux sans problème partir sur un SSD pour le système et un HDD pour les données. Pour la tailles des deux, ça reste spécifique à toi...
Si tu es short question budget, je ne suis toujours pas convaincu que 64Go de Ram soit utile à tout le monde, ça dépend surtout de ton utilisation. Dans tous les cas, tu peux tout à fait envisager de partir sur 2x16Go de RAM dans un premier temps, puis de rajouter 2x16Go plus tard si tu en as besoin
A ma connaissance, les actuels GPU arrivent à peine à saturer un port PCI-E 3.0 en 8x, parler d'un quelconque avantage du PCI-E 4.0 en 16x me parait improbable, même si je peux me tromper bien sur. Le PCI-E 4.0 étant finalement surtout fait pour le stockage via SSD nvme et les gros GPU de calcul type nvidia tesla.
Au passage, les nouvelles nvidia (RTX 3XXX) sont pour très bientôt (annonce vers fin aout / début septembre de tête). A voir aussi les futurs GPUs AMD en RDNA 2, même si j'aurais toujours tendance à privilégier nvidia, principalement pour cuda et le raytracing materiel. En tout cas les GPUs vont se renouveler chez nvidia et amd cette année donc autant attendre encore un peu selon moi.
Sinon pour le CPU, un threadripper me parait effectivement nickel
A voir pour la RAM, mais 2666Mhz, ca me parait faiblard (en tout cas, il est recommandé du 3200 voire 3600 pour les Ryzen, donc ca doit se valoir avec un threadripper) et l'architecture zen3 profite plutot pas mal des hautes fréquences et bas timing sur la RAM (dans la mesure du raisonnable bien sur) et voire aussi pour avoir une synchro avec l'infinity fabric (controleur mémoire des cpu amd actuellement), en gros pour de la ram en 3600Mhz, l'infinity fabric doit être à 1800 Mhz pour que le tout soit synchrone. Sinon cela rajoute une legere latence, réduisant de fait l'intéret de la monté en fréquence sur la RAM
@Nicolas Caplat A première vue c'est un poil plus complexe que ça pour
myObjs = selection as array
Le problème ici, c'est que tu veux choper la selection actuelle, hors la selection actuelle doit être le contrôler principal et pas les objets à modifier, à cause de:
CustAttributes.add $.modifiers[1] SPRING_Control_Custom_attribute"
donc ce qu'il va se passer ici, c'est que tu va stocker dans ton array 'myObjs' l'objet sur lequel tu ajoutes le custom attrib
il faut donc changer l'une des deux lignes de codes dans ce cas, soit hard coder la manière dont tu récupères 'myObjs' (en utilisant par exemple les noms des objets), soit hard coder l'objet sur lequel tu veux ajouter le custom attrib. Et à mon avis aucune des deux méthodes d'ailleurs n'est à conseiller, le hard coding étant à bannir . Imagine un simple changement de nom, et faut reprendre le script, la misère...
Pour ce genre de cas, ce qu'il vaut mieux faire à mon avis, c'est avoir dans la def du custom attrib une partie parameters avec soit un '#nodeTab' soit un '#maxObjectTab'
SPRING_Control_Custom_attribute = attributes custom_Attributes
(
parameters SpringControlParms rollout:SpringControlRollout
(
nodeArray type:#nodeTab tabSizeVariable:true tabSize:0
)
rollout SpringControlRollout "Spring Control" (...)
)
ou encore mieux en utilisant des weaks references
SPRING_Control_Custom_attribute = attributes custom_Attributes
(
parameters SpringControlParms rollout:SpringControlRollout
(
weakRefArray type:#maxObjectTab tabSizeVariable:true tabSize:0
)
rollout SpringControlRollout "Spring Control" (...)
)
et avoir par exemple un bouton en plus dans le rollout pour selectionner et stocker les objets à modifier derrière. Et ajouter au passage les deux paramètre type float pour "Mass" et "Drag", ce qui permet au passage d'accéder à tout ça par d'autre moyen, puisque ca devient de vrai parametre du contrôleur ($.modifiers[1].custom_Attributes.Mass via mxs par exemple), entre autres avantages (retenir la valeur actuelle par exemple).
Certes ca complexifie le tout, mais bon... J'ai proposé à @Balboza qu'on regarde ça ensemble quand il aura le temps, je te transmettrais le tout si tu es intéressé
Si je comprend bien, à chaque fois que tu sélectionnes ton spring, la valeur affiché du spinner dans le control panel est celle par default ?
Si c'est le cas et de tête (je n'ai pas touché à tout ça depuis, pfioouuuu... ? ), @Nicolas Caplat est sur la bonne voie, il faut que tu rajoutes un truc dans ce genre dans la définition de ton rollout:
rollout SpringControlRollout "Spring Control"
(
spinner spn_Mass "Height" range:[0,2000,500] type:#float
spinner spn_Drag "Height" range:[0,10,2] type:#float
on SpringControlRollout open do
(
spn_Mass.value = $.position.controller.getMass -- je ne connais pas la syntaxe exacte pour ce contrôleur, à vérifier
spn_Drag .value = $.position.controller.getDrag -- je ne connais pas la syntaxe exacte pour ce contrôleur, à vérifier
)
on spn_Mass changed val do $.position.controller.setMass val
on spn_Drag changed val do $.position.controller.setDrag val
)
Au passage, je te conseille de lire la doc sur Scripted Plugins ansi que sur Scripted Utilities and Rollouts
d'ailleurs, je constate que tu n'a pas de parameters dans ton custom attributes, c'est plutôt important car c'est ce qui permet de rajouter tes propres parametres à un objet, quelque chose du genre:
$.myParameter01
$.myParameter02
etc..., le tout link justement avec l'ui dans le rollout, et qui te permet de modifier ces valeurs ailleurs. Pas forcement necessaire en fonction de ce que tu veux faire mais généralement utile.
Sinon je te constellerais aussi peut-être de démarrer par quelque chose de plus simple que les custom attributes et les animations controler, qui sont de réel plaie a dev...
N'hésite pas à partager une simple scène de test avec les scripts en question si tu veux que je regarde ça plus en détails
Ca à toujours été le cas, on a toujours eu des démos technique de fou mais aucun jeu n'est jamais parvenus à ce niveau. J'ai même en tête certaine démo technique sortis il y a quasiment 10 ans et qui sont toujours loin devant les jeux les plus poussés actuellement.
Au passage, je dirais même que le "grand public" (donc corrige moi si je me trompe ici, mais aka les "gamers") ne sont pas franchement la cible, puisque ce ne sont pas eux qui utilisent les moteurs de jeu.
En revanche, et c'est quelque chose qu'il est bien souligné dans la démo d'ailleurs, mais nanite par exemple est là, manifestement fonctionnel et va réellement permettre un gain en productivité énorme. Je ne parle même pas forcement de charger directement des scans 3D (je comprends pas, mon projet fait 1.5 Terabytes... ), mais la possibilité de charger des modèles nettement moins optimisés pour du temps réel ET ne pas à avoir à faire de LOD est quelque chose d'excellent (je me suis assez arraché la tête sur cette question pour en parler xD).
Qui plus est, ça ouvre aussi à nettement plus d'industrie que le jeux vidéos, typiquement l'archviz ou le cinema, qui pour certain n'auront pas de soucis à avoir des projets excessivement massif, sachant que derrière il sera rendu uniquement des images et vidéos...
Au passage, je trouve l'article de Lidia quelque peu acerbe sur certain point. Alors oui nvidia avait par exemple fait une demo technique similaire (celle des astéroids, que j'avais vu d'ailleurs et qui m'avait bluffé), mais la dernière fois que j'ai vérifié, nvidia ne produit pas de moteur de jeux, juste de la R&D (qui sert principalement à vendre son propre matos, ne l'oublions pas). Epic n'a certainement pas indiqué avoir tout fait lui-même, mais il y a tout de même une énorme différence entre une "simple" démo technique créé et optimisé dans un seul et unique but, et un moteur de jeux fonctionnel qui utilise ladite tech. Il en vas de même pour le ray-tracing en temps réel et tout plein d'autre chose.
Faisant du temps-réel à titre pro depuis 10 ans maintenant, je suis clairement ravis de voir ça arriver dans un soft de production et plus juste dans des démo technique sortis de chez nvidia, peut m'importe qui à fait le taf derrière, c'est juste excellent.
Sans oublié que l'UE4 et le 5 sont désormais gratuit (sans parlé de megascan et autre) tant qu'on à pas généré un million de $ sur le projet. Et ca, ca met une toute aussi belle claque que la démo
Ca à toujours été le cas, on a toujours eu des démos technique de fou mais aucun jeu n'est jamais parvenus à ce niveau. J'ai même en tête certaine démo technique sortis il y a quasiment 10 ans et qui sont toujours loin devant les jeux les plus poussés actuellement.
Au passage, je dirais même que le "grand public" (donc corrige moi si je me trompe ici, mais aka les "gamers") ne sont pas franchement la cible, puisque ce ne sont pas eux qui utilisent les moteurs de jeu.
En revanche, et c'est quelque chose qu'il est bien souligné dans la démo d'ailleurs, mais nanite par exemple est là, manifestement fonctionnel et va réellement permettre un gain en productivité énorme. Je ne parle même pas forcement de charger directement des scans 3D (je comprends pas, mon projet fait 1.5 Terabytes... ), mais la possibilité de charger des modèles nettement moins optimisés pour du temps réel ET ne pas à avoir à faire de LOD est quelque chose d'excellent (je me suis assez arraché la tête sur cette question pour en parler xD).
Qui plus est, ça ouvre aussi à nettement plus d'industrie que le jeux vidéos, typiquement l'archviz ou le cinema, qui pour certain n'auront pas de soucis à avoir des projets excessivement massif, sachant que derrière il sera rendu uniquement des images et vidéos...
Au passage, je trouve l'article de Lidia quelque peu acerbe sur certain point. Alors oui nvidia avait par exemple fait une demo technique similaire (celle des astéroids, que j'avais vu d'ailleurs et qui m'avait bluffé), mais la dernière fois que j'ai vérifié, nvidia ne produit pas de moteur de jeux, juste de la R&D (qui sert principalement à vendre son propre matos, ne l'oublions pas). Epic n'a certainement pas indiqué avoir tout fait lui-même, mais il y a tout de même une énorme différence entre une "simple" démo technique créé et optimisé dans un seul et unique but, et un moteur de jeux fonctionnel qui utilise ladite tech. Il en vas de même pour le ray-tracing en temps réel et tout plein d'autre chose.
Faisant du temps-réel à titre pro depuis 10 ans maintenant, je suis clairement ravis de voir ça arriver dans un soft de production et plus juste dans des démo technique sortis de chez nvidia, peut m'importe qui à fait le taf derrière, c'est juste excellent.
Sans oublié que l'UE4 et le 5 sont désormais gratuit (sans parlé de megascan et autre) tant qu'on à pas généré un million de $ sur le projet. Et ca, ca met une toute aussi belle claque que la démo
Ca à toujours été le cas, on a toujours eu des démos technique de fou mais aucun jeu n'est jamais parvenus à ce niveau. J'ai même en tête certaine démo technique sortis il y a quasiment 10 ans et qui sont toujours loin devant les jeux les plus poussés actuellement.
Au passage, je dirais même que le "grand public" (donc corrige moi si je me trompe ici, mais aka les "gamers") ne sont pas franchement la cible, puisque ce ne sont pas eux qui utilisent les moteurs de jeu.
En revanche, et c'est quelque chose qu'il est bien souligné dans la démo d'ailleurs, mais nanite par exemple est là, manifestement fonctionnel et va réellement permettre un gain en productivité énorme. Je ne parle même pas forcement de charger directement des scans 3D (je comprends pas, mon projet fait 1.5 Terabytes... ), mais la possibilité de charger des modèles nettement moins optimisés pour du temps réel ET ne pas à avoir à faire de LOD est quelque chose d'excellent (je me suis assez arraché la tête sur cette question pour en parler xD).
Qui plus est, ça ouvre aussi à nettement plus d'industrie que le jeux vidéos, typiquement l'archviz ou le cinema, qui pour certain n'auront pas de soucis à avoir des projets excessivement massif, sachant que derrière il sera rendu uniquement des images et vidéos...
Au passage, je trouve l'article de Lidia quelque peu acerbe sur certain point. Alors oui nvidia avait par exemple fait une demo technique similaire (celle des astéroids, que j'avais vu d'ailleurs et qui m'avait bluffé), mais la dernière fois que j'ai vérifié, nvidia ne produit pas de moteur de jeux, juste de la R&D (qui sert principalement à vendre son propre matos, ne l'oublions pas). Epic n'a certainement pas indiqué avoir tout fait lui-même, mais il y a tout de même une énorme différence entre une "simple" démo technique créé et optimisé dans un seul et unique but, et un moteur de jeux fonctionnel qui utilise ladite tech. Il en vas de même pour le ray-tracing en temps réel et tout plein d'autre chose.
Faisant du temps-réel à titre pro depuis 10 ans maintenant, je suis clairement ravis de voir ça arriver dans un soft de production et plus juste dans des démo technique sortis de chez nvidia, peut m'importe qui à fait le taf derrière, c'est juste excellent.
Sans oublié que l'UE4 et le 5 sont désormais gratuit (sans parlé de megascan et autre) tant qu'on à pas généré un million de $ sur le projet. Et ca, ca met une toute aussi belle claque que la démo
Ca à toujours été le cas, on a toujours eu des démos technique de fou mais aucun jeu n'est jamais parvenus à ce niveau. J'ai même en tête certaine démo technique sortis il y a quasiment 10 ans et qui sont toujours loin devant les jeux les plus poussés actuellement.
Au passage, je dirais même que le "grand public" (donc corrige moi si je me trompe ici, mais aka les "gamers") ne sont pas franchement la cible, puisque ce ne sont pas eux qui utilisent les moteurs de jeu.
En revanche, et c'est quelque chose qu'il est bien souligné dans la démo d'ailleurs, mais nanite par exemple est là, manifestement fonctionnel et va réellement permettre un gain en productivité énorme. Je ne parle même pas forcement de charger directement des scans 3D (je comprends pas, mon projet fait 1.5 Terabytes... ), mais la possibilité de charger des modèles nettement moins optimisés pour du temps réel ET ne pas à avoir à faire de LOD est quelque chose d'excellent (je me suis assez arraché la tête sur cette question pour en parler xD).
Qui plus est, ça ouvre aussi à nettement plus d'industrie que le jeux vidéos, typiquement l'archviz ou le cinema, qui pour certain n'auront pas de soucis à avoir des projets excessivement massif, sachant que derrière il sera rendu uniquement des images et vidéos...
Au passage, je trouve l'article de Lidia quelque peu acerbe sur certain point. Alors oui nvidia avait par exemple fait une demo technique similaire (celle des astéroids, que j'avais vu d'ailleurs et qui m'avait bluffé), mais la dernière fois que j'ai vérifié, nvidia ne produit pas de moteur de jeux, juste de la R&D (qui sert principalement à vendre son propre matos, ne l'oublions pas). Epic n'a certainement pas indiqué avoir tout fait lui-même, mais il y a tout de même une énorme différence entre une "simple" démo technique créé et optimisé dans un seul et unique but, et un moteur de jeux fonctionnel qui utilise ladite tech. Il en vas de même pour le ray-tracing en temps réel et tout plein d'autre chose.
Faisant du temps-réel à titre pro depuis 10 ans maintenant, je suis clairement ravis de voir ça arriver dans un soft de production et plus juste dans des démo technique sortis de chez nvidia, peut m'importe qui à fait le taf derrière, c'est juste excellent.
Sans oublié que l'UE4 et le 5 sont désormais gratuit (sans parlé de megascan et autre) tant qu'on à pas généré un million de $ sur le projet. Et ca, ca met une toute aussi belle claque que la démo
en passant: http://www.comptoir-hardware.com/actus/software-pilotes/39492-et-une-faille-de-securite-de-plus-chez-dell-.html
Après faudrait pas croire que c'est mieux ailleurs avec ces bloatwares...
SugaR got a reaction from archimi in Nouvelle station (Dell ou pas)
SugaR reacted to popol in VEX Wrangle Cheat Sheet
SugaR got a reaction from Nicolas Caplat in Nouvelle station (Dell ou pas)
SugaR got a reaction from TChadail in GITHUB: Imaoki FlexUI
SugaR got a reaction from kilkil3d in Nouvelle config.
SugaR got a reaction from popol in Houdini Flip fluid station de travail
SugaR got a reaction from Miaz3 in Unreal Engine 5 Revealed